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instruments, including the typicaiiy large monetary 
transaction sizes . 

The advent of computer technology is having a rnajor impact on 
the practice on the buying and selling of financial 
5 instruments. In particular, computer systems have been 

implemented to facilitate securities trading in a variety of 
ways. A recent example of such a systein is described in U.S. 
Patent No. 5,924,082, which allows buyers and sellers located 
at remote computer terminals to engage in buy/sell 
10 transactions. The system automatically matches potential 

parties to a transaction, based upon ranking information, and 
then permits the potential parties to electronically negotiate 
some or all terms of the transaction* 

The use of computerized systems is* becoming widespread for the 
15 trading of equity instruments. However, the development of a 
computerized trading system for fixed income products, which 
takes full advantage of the potential of modern data 
processing systems to reduce market costs, has yet to be 
realized. 

t 

20 sm4MARY OF THE INVENTION 

The inventors have developed a fixed income trading system 
that provides traders (defined as persons or entities that buy 
and/or sell securities) with a computerized trading venue. 
Fixed instruments are entered into the fixed instrument 

25 trading system and are organized into books for system wide 
display. A book is defined by a set of bids and/or offers 
regarding an instrument and by a settlement date. Traders 
enter "firm" orders (e.g., offers and bids that can be 
immediately executed against at a stated price) into the 

30 respective instrument books, which are then displayed system 
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TITLE OF THE INVENTION 

APPARATUS r METHOD AND PROGRAM 
FOR A FIXED INCOME TRADING SY^STEM 

BACKGROUND OF THE INVENTION 
Field of the Invention 

The present invention relates generally to a method and 
apparatus for trading securities, and in particular, to 
5 trading fixed income instruments through a computerized 
system- 
Related Background Art 

Perhaps the oldest mechanism for facilitating the trading of 
financial instruments is the market concept, in which buyers 
10 and sellers (or their agents) collect at a single location and 
negotiate the price at which a purchase or salej occurs. 

Markets can be highly efficient for both buyers and sellers. 
Some exchange models have an organization that provides a 
floor where dealers can engage in buy and sell transactions, 
15 either directly or through specialists who maintain liquidity 
in particular instruments. 

Exchange models are used for the purchase and sale of 
relatively fungible items, such as equity financial 
instruments, v/hich have characteristics promoting liquidity: 
20 they are widely held, frequently traded and have a relatively 
large number of shares outstanding. However, exchanges have 
not been extensively used for buying and selling fixed income 
instruments, due to the complex issues surrounding fixed 
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"bid" can be defined as an order to buy. A trader can moni-or 
orders and transactions through a graphic user interface 
("GUI") to the system. Traders can "aggress" an order (e.g., 
hit a bid, or lift an offer) through the GUI and system. A 
5 hit can be defined as an acceptance of a bid (e.g., a trader 
"hitting" a bid is willing to sell at a bid price or higher). 
A lift can be defined as an acceptance of an offer (e.g., a 
trader "lifting" an order is willing to buy at the offer 
.price, or lower). A successfully hit bid, or a lifted offer, 
10 results in an executed trade. Executed trades can be 

- automatically forwarded to a clearing entity for settlement. 
Settlement can be defined as a process where a first trader 
exchanges currency or value for a second trader's security. 

The present invention significantly reduces transactional 
15 costs associated with disseminating information regarding 

fixed income instruments. Furthermore, the present invention 
simplifies instrument trading by organizing and centralizing 
instrument information. The present invention also provides 
redundant backup features to ensure system vitality, 

20 Accordingly, one aspect of the present invention is to provide 
a trading system for trading fixed income instruments- The 
system includes at least two server computers. Each server 
computer includes a first interface to communicate with a 
server computer; a second interface through which orders are 

25 received by the system; at least one processor for executing 

computer code; a first database pertaining to trading activity 
through the system in a first trading market; a second 
database pertaining to trading activity through the system in 
a second trading market; at least one cache storing 

30 information regarding market activity in the respective first 
or second market; and a memory having computer executable code 
stored thereon. The code is for (i) updating the first and 
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synchronizing the updates; and (ii) processing orders from 
each respective trading market. 

Another aspect of the present invention is to provide a 
trading system, v/herein each of two server computers is 
5 located in a geographically separate location. The trading 

system, further includes at least one trader site including at 
least one application server and a workstation connected to 
the at least one application server- The at least one 
application server contains a cache having at least a copy of 
10 the information in the first database stored thereon. The 

system includes computer executable code that i) updates the 
cache in the at least one application server, and ii) 
synchronizes the updates with the updates to the first and 
second databases. 

15 Another object of the present invention is to provide a 

trading system having computer executable code stored in a 
memory, wherein the code maintains at least one instrument 
book defined by a set of bids and offers and by a settlement 
date. The code changes a status of the at least one 

20 instrument book. A status includes open, closed, inactive and 
retired. 

Another object of the present invention is to provide a 
trading system having code stored in a memory, the code ranks 
a bid having a highest price first among other bids in at 

25 least one book. The code also ranks an offer having the 
lowest price first among other offers in the at least one 
book. The code also ranks passive orders having a same price 
in the at least one book on a first come, first serve basis 
v;ith respect to each other. The code processes aggressive 

30 orders on a first come, first serve basis, and removes from 

the at least one book a passive bid or passive offer once the 
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passive bid or passive offer has been executed. The code also 
validates orders. 

Another object of the present invention is to provide a 
trading system with a user terminal interfaced with the 
5 apparatus. Preferably, at least one book is configured for 

display through the user terminal. The trading system contains 
code to filter data transmitted to the user terminal. 

Yet another object is to provide a trading system with code to 
cause the system to transfer information related to executed 
10 transactions through the trading system to at least one 
clearing entity. 

Still another object of the present invention is to provide a 
trading apparatus * The apparatus includes at least one 
network server having: at least one processor which executes 

15 computer executable code; an interface through which orders 
are received by the trading apparatus; and a memory for 
storing computer executable code. The code includes steps for 
(i) maintaining at least one instrument book defined by a set 
of bids and offers and by a settlement date; (ii) processing 

20 passive orders; (iii) processing aggressive orders; (iv) 
executing trades based on the aggressive orders; and (v) 
processing a sweep order for the at least one instrument book. 

According to one aspect, the sweep order is an order to 
aggress multiple passive orders at a selected price option and 

2 5 amount. The code aggresses passive orders to fill the sweep 
order by sequentially i) executing shown amounts of passive 
orders at the selected price; ii) executing reserve amounts at 
the selected price when needed to fill the sweep order; and 
iii) executing passive orders at a next price when needed to 

30 fill the sweep order. The code expires a first passive order 
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determines that the first passive order was submitted by a 

trader v;ho also submitted the sweep o^der 3pH i ; \ x.u 

-^^i, aii^a XX) the code 

executes a second passive order that is listed below the -i-s- 

passive order. 

Yet another object of the present invention is to provide a 
trading apparatus that receives a first passive order that 
includes price and amount information. The first passive 
order further includes shown amount information, and the code 
determines a reserve amount from the shown amount. At least 
oae user terminal is interfaced with the trading apparatus and 
the code conditionally conceals the reserve amount from the at 
least one user terminal. The codes conveys the reserve amount 
to the at least one user terminal when a condition includes a 
user who entered the first passive order. The code also 
executes a shown amount prior to executing a reserve amount. 
The code also executes shown amounts for orders at a same 
price in an instrument book before executing reserve amounts 
for the orders at the same price. 



Still another object of the present invention is to provide a 
trading apparatus including at least one network server. The 
at leas, one network server includes: at least one processor 
whxch executes computer executable code; an interface through 
whxch orders are received by the trading apparatus; and a 
memory for storing computer executable cods. The code 
includes steps for (i) maintaining at least one instrument 
book defined by a set of bids and offers and by a settlement 

da^e; (xx) processing oassive orders- r.^^ 

^ - wj.uc:j.b, (xxx; processxng 

aggressive orders; (iv) executim -r;,H^^ u 

, c:.\c:(-u\.xng urades based oa th^^ 

aggressive orders. The steps process aggressive orders each 
havxng instrument ideatif icatxon , price oo.ion information 
amount information and minimum amount for execution 
information . 
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According to yet another aspect, the trading apparatus 
includes code to execute a trade only when a total amount of 
shown and reserve amounts for orders at the order price option 
in at least one instrument book equals at least the minimum 
5 amount for execution. Preferably, the code generates an 

execution notification regarding the order only when a trade 
is executed. 

Still another object of the present invention is to provide a 
trading apparatus, having at least one network server, 

10 including: at least one processor which executes computer 
executable code; an interface through which orders are 
received by the trading apparatus; and a memory for storing 
computer executable code. The code includes steps for (i) 
maintaining at least .one instrument book defined by a set of 

15 bids and offers and by a settlement date; (ii). processing 

passive orders; (iii) processing aggressive orders; and (iv) 
executing trades based on the aggressive orders. The steps 
process aggressive orders each having instrument 
identification^ price option criteria, amount information, and 

2 0 a post residual authorization, 

I. 

According to one aspect, a trading apparatus includes code 
stored in a memory that converts an unfilled balance of the 
first aggressive order into a passive order having an 
aggressed-on price. The code posts the unfilled amount in at 
25 least one ins-trument book as a shown amount. Alternatively, 
the code posts a portion of the unfilled amount in the at 
least one instrument book as a shown amount and the remainder 
as a reserve amount. 



30 



Still another object is to provide a trading 
including at least one network server having 
processor which executes computer executable 



apparatus 
: at least 
code ; an 
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apparatus; and a memory for storing ccmputer executable code. 
The code includes steps for (i) maintaining at least one 
instrument book defined by a set of bids and offers and by a 
settlement date; (ii) processing passive orders; (iii) 
5 processing aggressive orders; (iv) executing trades based on 

the aggressive orders; and (v) suspending all orders submitted 
by a user through a user terminal when communication with the 
user terminal is interrupted. 

Another object of the present invention is to provide a 
10 trading apparatus with at least one network server, including: 
at least one processor which executes computer executable 
code; an interface through which orders are received by the 
trading apparatus; and a memory for storing computer 
executable code. The code includes steps for (i) maintaining 
15 at least one instrument book defined by a set of bids and 
offers and by a settlement date; (ii) processing passive 
orders; (iii) processing aggressive orders; (iv) executing 
trades based on the aggressive orders; and (v) canceling all 
orders received from a user through a user terminal in 
20 response to a user generated bulk cancel request. 

Another object of the present invention is to provide a 
trading apparatus having at least one network server, 
including: at least one processor which executes computer 
executable code; an interface through which orders are 

2 5 received by the trading apparatus; and a memory for storing 
computer executable code. The code includes steps for (i) 
maintaining at least one instrument book defined by a set of 
bids and offers and by a settlement date; (ii) processing 
passive orders; (iii) processing aggressive orders; (iv) 

30 executing trades based on the aggressive orders; and (v) 
suspending all orders received from a user through a user 
terminal in response to a user generated bulk suspend request. 
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Yet another object of the present invention is to provida a 
trading apparatus having at least one network server, 
including: at least one processor which executes computer 
executable code; an interface through which orders are 
received by the trading apparatus; and a memory for storing 
computer executable code. The code includes steps for (i) 
maintaining at least one instrument book defined by a set of 
bids and offers and by a settlement date; (ii) processing 
passive orders; (iii) processing aggressive orders; (iv) 
executing trades based on the aggressive orders; and (v) 
converting passive orders into an aggressive orders and 
executing the converted aggressive orders at a top of book 
price, when the passive orders invert a market. A first 
passive order inverts the market when the first passive order 
includes a bid having a higher price than the lowest priced 
offer in the at least one instrument book, or when the first 
passive order includes an offer having a lower price than the 
highest priced bid in the at least one instrument book. 

Yet another object of the present invention is to provide a 
trading apparatus having at least one network server 
including: at least one processor which executes computer 
executable code; an interface through which orders are 
received by the trading apparatus; and a memory for storing 
computer executable code. The includes steps for (i) 
maintaining at least one instrument book defined by a set of 
bids and offers and by a settlement date; (ii) processing 
passive orders; (iii) processing aggressive orders; (iv) 
executing trades based on the aggressive orders; and (v) 
expiring all orders at the end of a trading day. 



Another object of the invention is to provide 
apparatus having at least one network server, 
least one processor which executes computer e 



a trading 
including at 
xecutable code; 
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apparatus; and a memory for storing computer executable code. 
The code includes steps for (i) maintaining at least one 
instrument book defined by a set of bids and offers and by a 
settlement date; (ii) processing passive orders; (iii) 
5 processing aggressive orders; (iv) executing trades based on 
the aggressive orders; and (v) expiring orders based on user 
selected criteria . 

Another object of the present invention is to provide media 
containing computer executable code. The code is to generate 

10 a graphic user interface invocable by programable software for 
use in a fixed income trading system. The system provides a 
computerized venue for trading instruments. The system 
receives orders including bids and offers for individual 
instruments submitted to the system. The system maintains at 

15 least one book defined by a set of orders and by a settlement 
date. The graphic user interface is for employment on a 
trader work station connected to the system. The computer 
executable code includes steps to generate a first window 
having a first display region displaying a top of book view, a 

20 second display region displaying a key issues view, a third 
region displaying a depth of book view, and a forth region 
including at least one user activatible button to invoke an 
order entry dialog box through which a user inputs order 
requests into the system. The computer executable code 

25 further includes steps to generate a region including a user 

activatible button for displaying a floating book window. The 
floating book includes a depth of book view and a region 
including user activatible buttons to invoke at least one 
order entry dialog box. 

-30 In still another embodiment, media containing computer 

executable code to generate a graphic user interface invocable 
by a software program is provided. The graphic user interface 
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provides a computerized venue for trading instruments . The 
code includes steps to generate a first window displaying a 
scrolling list of real-time market activity that occurs 
through the system. The first window including a first region 

5 having a pull-down menu for a user activatible filter for 

selecting a subset of activity to view for real-time display. 
The code includes steps to generate a second window displaying 
a client-specific blotter including order history information, 
order status information, and user activated transactions, 

0 wherein a broker accessing the second window can interface 
with the system on behalf of the specified client. 

In another embodiment, a network trading system is provided. 
The system includes at least one server including at least one 
processor for executing computer code, an interface through 

5 which a user gains access to the system, and at least one 

memory having computer executable code stored thereon. The 
code: (i) tracks activity through the system with respect to 
individual trading instruments; (ii) organizes for real-time 
display the tracked activity of individual tradying 

0. instruments; and (iii) displays to the user a subset of the 
tracked activity. 

These and other objects, features and advantages will be 
apparent from the following description of the preferred 
embodiments of the present invention. 

5 BRIEF DESCRIPTION OF THE DRAWINGS 

Figure 1 is a diagram illustrating a system overview of a 
fixed income trading system. 



Figure 2a is a diagram showing a three-domain partitioning 
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diagram showing an embodiment having two network servers per 
each data center of Figure 1. 

Figure 3 is a diagram illustrating individual components 
within a network server. 

Figure 4 is a diagram showing a communication scheme within 
the core component domain, including a data synchronization 
data stream and communication involving an AQP core component. 

Figure 5 is a diagram illustrating a retransmission request 
from a consuming component. 

Figure 6 is a diagram illustrating heartbeats issued from the 
AQP core component - 

Figure 7 is a diagram illustrating the redundancy features of 
a DR Replicator core component. 

Figure 8 is a diagram illustrating MCP instances in the core 
and gateway domains . 

I, 

Figure 9 is a diagram illustrating a possible domain 
configuration for a data center of Figure 2b. 

Figure 10 is a diagram illustrating a cluster management 
channel, and a failover procedure involving the MCP. 

Figures 11a- Lid are diagrams illustrating how instrument data 
i5 supplied to the system of Figure 1. 

Figures 12a-12c are diagrams illustrating how client data is 
supplied to the system of Figure 1 via a client database 
adapter core component. 
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Figures 13a-13e illustrate a function cf a Back Office Adapter 
component operating within the system illustrated in Figure 1. 

Figures 14a-14h illustrate a procedure for entering and 
executing orders through the system illustrated in Figure 1, 

Figure 15 is a diagram illustrating network connections for 
the system illustrated in Figure 1. 

Figure 16 is a diagram illustrating a transaction in a U.S. 
market through the system illustrated in Figure 1, between a 
Firm A and a Firm B. 

Figures 17a and 17b are diagrams showing an interaction 
between the system of Figure 1 and outside clearing entities 
for U.S. markets - 

Figures 18a- 18c are diagrams illustrating a component commit 
operation, which can change an object's status. 

Figure 19 is a diagram illustrating how a trade occurs through 
the system of Figure 1 . 

Figure 20 is a diagram illustrating a settlement process in a 
European market. 

Figure 21 is a diagram illustrating how a TRAX system reports 
matching results back to traders in a European market. 

Figure 22 is a diagram illustrating a settlement confirmation 
in a European market. 

Figure 23 is a screen shot showing a Login dialog box of a 
trader GUI . 
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Figure 24 is a screen shot showing a Main Market, view of the 
trader GUI . 

Figure 25 is a screen shot shoving an Order Entry dialog box 
of the trader GUI. 

5 Figure 2 6 is a screen shot showing a Hit Bid dialog box of the 
trader GUI. 

Figure 27 is a screen shot showing a Market pull-down for the 
trader GUI • 

Figure 2 8 is a screen shot showing a Preferences dialog box of 
10 the trader GUI, 

Figure 29 is a screen shot showing an Offer Order entry box of 
the trader GUI. 

Figure 30 is a screen shot showing a Take Offer dialog box of 
the trader GUI. 



^ ■ . . . . - 

15 Figure 31 is a diagram illustrating an execution priority for 

s 

given shown and reserve amounts in an instrument book. 



Figure 32 is a screen shot showing a Sweeping the Book dialog 
box of the trader GUI . 

Figure 33 is a screen shot showing a Quick/Hit dialog box of 
2 0 the trader GUI. 

Figure 34 is a screen shot showing a Quick/Take dialog box of 
the trader GUI. 



Figure 35 is a flow diagram illustrating one aspect of an 
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Figures 36a-36c are screen shots showing a Blotter of the 
trader GUI , 

Figure 37 is a screen shot showing a Floating Book of the 
trader GUI. 

Figures 38a and '38b are screen shots showing Cancel Orders and 
Suspend Orders dialog boxes, respectively. 

Figure 39 is a screen shot showing an Execution Notification 
window of the trader GUI . - 

Figure 40 is a screen shot showing a window of the trader GUI 
having multiple Depth of Book views. 

Figure 41 is a screen shot of a broker GUI broker desk tool 
bar . 

Figure 42 is a screen shot of the broker GUI showing a real- 
time market monitor application. 

Figure 43 is a screen shot of the broker GUI showing a Create 
Market Monitor Filter dialog box for orders/trades. 

Figure 44 is a screen shot of the broker GUI showing a Create 
Market Monitor Filter dialog box for instruments. 

Figure 45 is a screen shot of the broker GUI showing a drop- 
down menu of instrument groupings . 

Figure 46 is a screen shot of the broker GUI showing a 
selected group according to Figure 45. 



Figure 47 is a screen shot of the broker GUI showing a client 
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Figure 43 is a screen shot of the broker GUI showing a list of 
trades . 

Figure 4 9 is a screen shot of the broker GUI showing a main 
market view, 

5 Figure 50 is a screen shot of the broker GUI showing a 

suspend/cancel feature of the present invention. 

Detailed Description of the Preferred Embodiments 

Figure 1 illustrates in schematic form the principal 
10 components utilized in the present invention. In particular, 
there is shown a fixed income trading system 100, which 
facilitates trading of fixed income instruments in respective 
trading markets - 

Overview of Capabilities of System 10 0 

15 From a trader's perspective, the system 100 allows users 

(e.g., "traders") to enter order requests that are displayed 
network-wide as firm bids to buy or offers to sell at a 
price/quantity for a particular fixed income instrument. All 
orders are preferably live; meaning, that they can be 

2 0 immediately executed against at a listed price. Traders can 
be remotely located at trading desks (e.g., user terminals) 
throughout the world, and communicate by means of desktop 
workstations or other information appliances that have the 
ability to communicate with the balance of system 100. 

25 System 100 allows traders or client users to manage orders (or 
a subset of orders), including tasks such as modifying, 
canceling, or suspending, or reinstating previously suspended 
orders, and allows a user to accept (e.g., "aggress") 
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system 100 further allows control of the amount of an order 
that is held in reserve. aad th erefo re not displayed publicly 
on the system. The term "reserve" refers to the portion of an 
order that is available for execution, but not displayed to • 
other traders. Reserve functionality helps traders avoid 
moving the market against them by not disclosing to other 
traders -the total amount of their orders. In a preferred 
embodiment for U.S. markets, the system does not indicate that 
a reserve amount exists for orders to anyone other than the 
order's owner. In a preferred embodiment for European 
markets/ the system (through a trader GUI) indicates an "R" if 
an order has a reserve amount. 

System 100 arranges offers and bids into books. A "book" is 
defined as a set of bids and/or offers that compete with each 
other for the same instrument and settlement date in the same 
market type (e.g., "type" refers to cash .or basis trading). 
If bids or offers exist for multiple settlement dates for a 
single security, they are preferably maintained in separate 
books . 

System 100 preferably allows a trader to accept a single 
order; or multiple orders simultaneously. Simultaneous 
acceptance is referred to as "sweeping the book." System 100 
sweeps the book by beginning with the best bid/offer (from the 
aggressor's standpoint) and accepting that order entirely, 
including- reserve amounts, before moving on to the next order 
at a next price. 

A further preferred aspect of the system 100 is an 
organization and display feature that allows a user to view 
trading activity on the system 100. A trader can access 
several different views of a book, including the "Top of 
Book," the "Depth of Book/' and "Key Issues." The "Top of 
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bid/offer for securities on the sysrem 100. The "Depth of 
Book" view includes real-time information about a security's 
active orders on the system 100. The "Key Issues" view 
provides information which allows a user to create a 
5 customized view of the top of the book activity for a specific 
set of securi-ties. Furthermore, the system 100 allows a user 
to maintain a "blotter" of activity. The blotter is a real- 
time work space that enables users to monitor and manage all 
relevant details about their orders and trades. 

10 • In addition to the above-mentioned advantages, the system 100 
includes many other preferred functional features. For 
example, the system 100 preferably has a user authorization 
and permission protocol. These protocols provide user-based 
restrictions on selected system functions. For example, the 

15 system 100 can verify whether a user has clearance to access 
the system. This verification can be facilitated through 
system generated ID codes, electronic signatures or through 
terminal passwords, for example. An order validation function 
is also provided to ensure that orders follow established 

20 "trade execution rules," as well as ensuring users are advised 
of entry mistakes. Price/ time priority is a trade execution 
rule that specifies how orders are sequenced for display and 
execution on the system 100. From a display perspective, 
currency bids are sequenced from highest to lowest price - 

25 Yield and discount bids are sequenced from lowest to highest 
price. Currency offers are sequenced from lowest to highest. 
Yield and Discount offers are sequenced from highest to lowest 
price. Within a single :^ric„e^ oj:^rs are sequenced oldest to 
newest. From an execution perspective, the trade execution 

30 rules preferably prioritize executions as follows: i) the 

system 100 finds the best price,,, and the best price executes 
first, and ii) if multiple orders at a given price exist, the 
svsterr- takes the oldest best price first (e.g., the price 
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associated with the order that has been on the system Longer 
than any other order at that pries). 

The system also preferably includes order entry functions such 
as various pricing options, reserve/display capabilities, 
order modification,- cancellations, and reinstatement 
capabilities, as are discussed below. Additionally, a trade 
execution function is provided to support bid/offer options. 
Also provided is a data filtering function to ensure that 
trader "blotter" views display only the information that is 
related to a given trader's market activity. Furthermore, the 
system provides real-time trade updates to all trader desktops 
system wide through a diverse range of processing functions 
such as object creation /management, data persistence and 
performance techniques. Other functions preferably include 
the creation of standard market level displays, a resiliency 
function to ensure data input from any trader desktop is not 
lost in the event of a hardware or software failure, 
commission calculation functions, support for clearing and 
settlement by providing links to external clearing facilities, 
. and Broker Desk tools (herein after "B-Desk tools") to enable 
brokers and system personnel to support system activity. A 
broker can be defined as a party that is neutral with* respect 
to a trade. The B-Desk tools provide brokers with the ability 
to view orders and transaction data, manage client 
information, set up book parameters, and maintain instrument 
information, for example. 

General Description of Svstem 100 

In Figure 1, trader desktops (e.g., workstations) 154, 154, 
175 and 188 are arranged to provide traders with an access 
point to system 100. A workstation is a computer preferably 
having a memory (e.g., RAM, ROM, and/or local fixed storage). 
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entry devices (e.g., a key board, mouse, light pen, touch 
sensitive monitor, etc.)- "^^e workstations are controlled by 
an operating systerr., such as Windows 98, from Microsoft 
Corporation. As will be appreciated by those skilled in the 
5 art, an equivalent system such as UWIX, could be used. 
Software is installed (e.g., stored in memory) on each 
workstation that produces a trader Graphic User Interface 
("GUI"), an example of which is shovm in Figure 24. As will 
be appreciated by those skilled in the art, the software can 
10 be stored on computer readable media, including CD-ROMs, 

floppy disks, removable media, magneto-optical media, fixed 
disks, flash memory, memory sticks, etc. The trader GUI will 
be discussed in greater detail below. 

Workstations 154 are preferably connected through a known _ 

15 firewall 153 to application servers 151 and 152. The 

application servers 151 and 152 provide object management 
processing, data caching services (to minimize system response 
time), and access to a virtual marketplace [e.g., instrument 
books and market resources) supplied via da^a center 110 and 

20 the core components 112. Together the application server 151 
and 152, firewall 153, and trader desks 154 form a trader site 
150. The trader site 150 is connected through an external 
services network 114 to a data center 110. As will be 
appreciated by those skilled in the art, a network can be 

25 maintained on secure, dedicated lines (e.g., a private 

network) or could incorporate a network such as the Internet. 
As will be appreciated by those skilled in the art, a trader 
site 150 could operate with only one server, but may employ 
multiple servers (as illustrated) depending on volume and 

30 resiliency requirements. 



Data center 110 includes at least one server 110a. As will be 
appreciated by those skilled in the art, a "server" is a 
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data between different points such as between a network and 
external sources. From a hardware standpoint, a server will 
typically include one or more components for performing the 
arithmetic and/or logical operations required for program 
execution, such as one or more microprocessors, A server will 
also typically include disk storage media such as one or more 
disk drives for program and data storage and random access 
memory (RAM) for temporary data and program instruction 
storage. From a software standpoint, a server computer also 
contains server software resident on the disk storage media, 
which when executed directs the server computer in performing 
its data transmissions and reception functions. Servers are 
offered by a variety of hardware vendors including Sun 
Microsystems, Inc. These servers can contain different types 
of server software, each type devoted to a different function, 
such as handling data from a particular source or transforming 
data from one format into another. 

In Figure 1, reference numbers 110 and 120 designate data 
centers. A data center is a trading "hub" for the system 100, 
through which trading activity and system management within 
the system 100 are controlled. 

In a preferred embodiment, each server in data centers 110 and 
120 is a Sun Enterprise 10000 server ("ElOk"), manufactured by 
Sun Microsystems, Inc., or a similar server platform- 
Documentation for the ElOK server can by obtained from Sun 
Microsystems, Inc. and through Sun's website at 
htt o : / / docs . sun . com (and various links). The server software 
runs on an operating system such as the Solaris 2.6 platform, 
developed by Sun Microsystems, which is stored on a disk 
storage device. 



The ElOk servers support partitioning. Partitioning is the 
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multiple smaller systems (or partitions), with each partition 
running its own instance of the operating system. Each 
partition is referred to as a dynamic system "domain." 
Dynamic system domains are logically isolated from each other 
5 within the server, which isolated configuration provides a 
highly secure and reliable environment for running multiple 
functions simultaneously. Domains can be dynamically 
configured without interrupting users or production. For 
example, domains can be created, allocated, and resized while 
10 a server is operational- Domain management is achieved 
. through 'a management console connected to the server. 

An example of a basic unit of a domain includes one system 
board, having up to four processors (such as a "Ultra-SPARC" 
processor), a four gigabyte memory and four I/O connections. 
15 In the example, each domain operates its own instance of the 
Solaris 2.6 operating environment software, as well as 
maintaining its own unique name, boot disk, disk connections ^ 
memory, CPUs, network and interconnect access — creating a 
fully functional, fully isolated partition. 

20 Because of the software and hardware independence, most 
software and nearly all hardware errors in a domain are 
confined to that domain and will not affect the rest of the 
server. The El Ok server can currently accommodate up to eight 
domains . 

25 As shown in Figure 2a, the server 110a is preferably 

configured or partitioned into three domains. The three 
domains include a database 111, core components 112, and a 
gateway 113. In an alternative emiDodirr.ent (e.g., the Figure 
2b embodiment), the data centers 110 and 120 each include two 

30 ElOks servers, which are each divided into three domains , 

Including both data centers 110 and 120, twelve (12) domains 
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appreciated by those skilled in the art, each domain is 
equivalent to a separate stand alone computer. 

Software is installed on broker terminals that produces a 
broker desk tools (e.g., B-Desk tools) Graphic User Interface 
("GUI"), an example of which is shown in Figure 41. As will 
be appreciated by those skilled in the art, the B-Desk tools 
software can be stored on computer readable media, including 
CD-ROMs, floppy disks, removable media, magneto-optical media, 
fixed disks, flash memory. mem.ory sticks, etc. In a preferred 
embodiment, brokers support the system and traders through a 
broker site, like trading site 150 shown in Fig. 1. 

System 100 preferably includes an interface to a client 
database 135. The client database 135 houses information 
regarding clients and their accounts and various trades made 
between respective clients. System 100 preferably also 
includes an interface to a terms and conditions database 136, 
which houses information regarding fixed income security 
information. As shown in Figure 1, data centers 110 and 120 
are networked to databases 135 and 136. Each data center 110 
and 120 preferably includes an interface to communicate with 
the other data center. 

The trading site 150 and data center 110 are also connected 
through the network 114 to a "backup" gateway 130. The backup 
gateway 130 connects traders to data center 120, in the event 
that the local data center 110 is unavailable for service, as 
discussed below. Gateway 130 could also include a client 
testing environment (e.g., UAT) . Data center 110 is 
interfaced with external clearing entities 137, 

Data center 120 also include a database 121, core components 
122, and gateway 123. Data center 120 is preferably locate 
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Database 120 is networked to a trader site 160, including 
application servers 161 and 162, firewall 163 and user 
terroinals 164, like those described above with respect to 
trader site 150. The trader site 160 and data center 120 are 
also connected to a backup gateway 140, as described above 
with respect to backup gateway 130. The backup gateway 140 
could also include a backup CMP. The CMP is described in 
further detail below. 

Figure 1 also illustrates remote client sites 170 and 180. 
•' For example, data center 120 may be located in London, while 
remote trader sites are located in Paris and Frankfurt, 
respectively. A remote gateway 171 and remote gateway 181 are 
preferably associated with each remote trading site 17 0 and 
180, respectively. The gateways 171 and 181 serve as an 
interface between the remote trading sites 170 and 180 and the 
data center 120. In this regard, the gateway 171 and 181 can 
each service multiple trading sites, thereby reducing overall 
connection costs. Without such a gateway, each trading site 
would need a direct connection to the database 120, which 
would increase the costs of the overall system 100. As 
previously mentioned, gateways provide connection ^services 
between the components located in the data centers and the 
application servers. The gateways also provide data caching 
and filtering to ensure that the data sent to a client or 
trader site, via his respective application server, is 
specific to that particular client or site. 

The data center 120 also interfaces with clearing entities 138 
that are authorized to operate in the corresponding geographic 
area. Authorization typically requires governmental approval 
and/or an operating license. In one preferred embodiment, 
data centers 110 and L20 each interface with clearing entity 
137 and 138. 
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Da-ta centers 110 and 120 preferably are located in distinct 
geographic locations, with each location having a unique 
trading market. For example, data center 110 could be located 
in the United States, with the corresponding trading market 
focusing on U.S. Treasury instruments. Similarly, Data center 
120 could be located in the United Kingdom. By fully 
integrating the system 100 and data centers 110 and 120, 
however, a trader in the geographic location of database 110 
can trade in both the local market, and in the market 
associated with the geographic location of database 12 0, and 
vice-versa. 

As will be appreciated by those skilled in the art, the Fixed 
Income Trading System 100 is based on an object-oriented 
design. Objects are defined by sets of data that describe 
conceptual real world entities and the programming logic that 
manipulates the data. For example, an "order" object includes 
all of the data needed to describe an order at a point in 
time, and the programming functions necessary to, process the 
data. The status of an object reflects the current object's 
data view. Preferably all processing by system 100 is 
transactional based. A transaction can be atomic, consistent, 
isolated or durable. An "atomic" transaction is a single 
logical unit of work. In an atomic transaction, all changes 
to an object by a system component are committed to the 
database 111, as well as the component's cache and an AQ 
("Advanced Queuing") synchronization stream. An atomic- 
transaction cannot be partially committed or partially 
aborted. A "consistent" transaction is a unit of work, which 
takes an object from one consistent state to another. An 
"isolated" transaction is one whose partial results during 
execution are hidden from other objects interacting with the 
system. A "durable" transaction is one whose results are 
persistent; that is to say, stored in a database. A 
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state changes are recorded as transactions, as discussed 
above . 

In the Fixed Income Trading System 100, objects and associated 
5 states are held in the system's databases 111 and 121, shown 
in Figure 2b. The databases 111 and 121 act as permanent 
persistent data repositories. In this sense, the databases 
111 and 121 track the current snapshot of all system activity. 
From the view point of data center 120, each component of the 

10 core components 112 has an associated cache 118, shown in 

• Figure 18c. The cache 118 acts a virtual data repository for 
each component in the data center's 110 and 120 servers. The 
cache 118 provides components with their own "working" copy of 
the database 111 (or database 121). The distributed working 

15 copy improves performance by reducing the database load. As 

will be appreciated, processing data is faster by manipulating 
objects stored in a memory cache, as .opposed to manipulating 
data stored on a fixed disk, for example. The cache 118 is 
preferably a separate cache for each component, however, most 

20 of the illustrated drawings refer to a component's cache as 
reference number. 118. In a preferred embodiment, the cache 
118 is managed by Power-Tier software, developed ^y 
Persistence, Inc. 

A technique called "optimistic versioning" is preferably 
25 implemented by the cache and a particular target object to 
guarantee transactional integrity of the system 100. This 
process is described with reference to Figures 18a through 
18c. As seen in Figure 18a, a exemplary component 112x 
processes data that changes an object's state. For example, 
30 component I12x could be a Book Manager 112c, AQ Publisher 

112a, or Bulk Request Manager 112g, or the like. In keeping 
with transaction based processing, the component records the 
state change by performing a single "commit operation" that is 
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operatioa is shown with reference to Figure 18b. As shown in 
Figure 18c, a commit operation simultaneously updates the 
component's local cache 118, updates the database 111, and 
creates and broadcasts a synchronization data stream to all 
system components. The data stream fully reflects the current 
state of the object. This synchronization data stream is 
consumed by a cache 118 of each system component to ensure 
that the component has a current state data image. As a 
result, the above-mentioned process ensures that all object's 
state changes result from transaction based processing and the 
updates 'reflecting the changes occur simultaneously 
systemwide. Hence, systemwide object integrity can be 
ensured. In a preferred embodiment, Oracle 8 Parallel Server, 
from Oracle, Inc., and Power-Tier, from" Persistence, Inc., are 
used to facilitate simultaneous updating of the database 111 
and the caches 118, respectively. 

Data Domains 

Each of the three domains 111, 112, and 113 will now be 
discussed in further detail with reference to Figures 1, 2a 
and 3. While the following discussion is from the perspective 
of data center 110, it will be appreciated that data center 
120 includes corresponding components. Database 111 is a 
store house for information pertaining to system activity, 
including order creation, market activity, book status, client 
information, authorizations and permissions, and final 
disposition of trades. In a preferred embodiment, the fixed 
income trading system 100 utilises Oracle 8 parallel database 
server software, from Oracle, Inc., for data management and 
data synchronization, including assisting with a data 
synchronization data stream. The database components run in 
their own domain on each server located at data center 110. 
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The server 110a, for example, maintains two ideatical images 
of the system's activity/ at any given time. A first image is 
committed to the database 111, and the second image is 
committed to each component's cache 118. As will be 
5 appreciated by those skilled in the art, the image of activity 
stored in the database 111 is persistent because it is always 
available, even if the system fails. However, the iniage 
stored in a component's cache 118 does not persist if that 
component fails. The databases 111 and 121 (including 

10 software discussed above) also provides the system 100 with a 
.synchronization data stream. Referred to Advanced Queuing 
C'AQ"), the synchronization data stream provides the system 
with a data stream that is identical to that which is 
committed to the database 111. The synchronization data 

15 stream is broadcast systemwide by the AQ Publisher 112a, 
discussed below- The data stream is consumed by system 
components to update their cache images. Updating each 
component ensures object state integrity systemwide. The data 
stream is identical to the information stored in the database 

20 111 because it is created in the satme operation that commits 
the data to the database 111, as well as to the cache 118 of 
the component generating a change. 

I 

Core Components 

The system's 100 core components will now be described in 
2 5 further detail. Preferably, a core component is a dedicated 

task module, or a block of computer executable code' (e.g., a 

software program), that runs on a domain of a server. 

Alternatively, as will be appreciated by those skilled in the 

art, a core comoonent could include a combination of software, 
30 memory, and hardware. Each component generally operates or 

controls different aspects of the overall system. 

Furthermore, comDonents may receive input data from other 
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and direct acriviries throughout the system 100. Each cf the 
system's LOO core components 112 are discussed below, with 
reference to Figure 3. The following discussion focuses on 
the components located on the severs 110a and 110b in data 
center 110. However, it will be understood that corresponding 
comDonents reside in the servers located in data center 120. 



AO Publisher 



The AQ Publisher ("AQP") 112a, shown in Figure 3, is a core 
component that runs in the active core domain of the servers 
located in each of the data centers 110 and 120. The AQP 112a 
facilitates delivery of the synchronization data stream to 
system components. The synchronization stream is created in 
the same operation that commits data to the database 111, as 
well as to the cache 118 of the component generating the 
change to a given object. Preferably, synchronization data 
message distribution meets three requirements. First, data 
messages should be distributed to system components as close 
to instantaneously as possible- Second, all object state 
changes {e.g., data updates) should be guaranteed to be 
available to every component that requires the update. Third, 
data updates should be provided to components in the order in 
which the changes occur. Preferably, the AQP 112a facilitates 
each of these objectives as described below. 

To better understand AQP processing, multicast messaging 
distribution and TIBCO, Inch's Rendezvous Distribution' is 
discussed. Multicast messaging distribution is utilized for 
message delivery throughout the system 100. As will be 
depreciated by those skilled in the art, multicast messa.ge 
distribution has the following characteristics: (i) a data 
string consists of multiple logical message queues; (ii) 
messages are sent in a single broadcast, without establishing 
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the message; (iii) an assumption is made that applications 
interested in the messages will be "Listening" and will 
therefore receive the messages; and (iv) multicast 
distribution is very efficient. A single message broadcast, 
5 for example, can service many applications or components. 

TIBCO, Inc.'s Rendezvous ("RV") messaging middlev^are is 
preferably utilized by the AQP 112a to facilitate multicast 
message distribution. As will be appreciated by those skilled 
in the art, the RV middleware converts the data stream into 

10 messages in RV format. Messages in RV format employ a 

subject-based naming convention, with each logical message 
queue having a unique base subject name. As will be 
appreciated by those skilled in the art, this type of subject- 
based naming convention allows the system's components to 

15 listen for message streams having a specific name, thereby 
facilitating the component's ability to listen only for the 
messages of interest. These messages are used to update each 
component's cache 118. By filtering data based on subject 
names, each component's cache 118 contains ^nly the object 

2 0 state information of interest to a given component. 

To facilitate multicast distribution, the AQP 1 12a*^converts 
the' AQ message streams to RV message streams, and broadcasts 
the RV messages to other components via the core RV ring. The 
core RV ring refers to a core network. The RV ring 

25 facilitates messaging between applications/components 

utilizing Rendezvous messaging. The core RV ring including 
processes called "rv daemons", which are part of TIBCO's 
Rendezvous product. As will be appreciated by those skilled 
in the art, a daemon is a software program, which in this 

30 case, handles processing for listening for objects with 
subject-based names. 
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An example of this distributioa scheme is given with reference 
to Figure 4. An exemplary core component 112x processes data 
and changes an object's state. By executing a commit 
'Operation, the process stream is stored in the component:' s 
5 112x cache 118 and in the database 111- An AQ message stream 
is generated, as discussed above. The message stream contains 
the same information that is contained in the database 111 and 
in the component's 112X cache 118. The data stream is 
directed through the AQP component 112a, through which RV 
10 formatted message streams for core components are issued. 

RV format provides a fast and efficient means for distributing 
messages, but does not address whether messages are received 
by individual components. To determine whether a message is 
received, a sequence number is assigned to each message within 

15 a given data stream. The core components 112 monitor the 

sequence numbers as messages are consumed from a given data 
stream. If the progression of sequence numbers is 
interrupted, the component recognizes that a message 
represented by a missing sequence number has been missed. If 

20 sequence messages are missed, the component in question 

requests a retransmission of the missing messages from the AQP 
112a. The AQP 112a sifts back through the AQ stream to find 
the missing message and retransmits the missing message to the 
complaining component . 

25 The system 100 provides a procedure for core components to 
recognize an AQP 112a failure. The AQP 112a periodically 
sends "heartbeat" messages at regular intervals to components 
in the event that an AQ synchronization stream does not 
contain any new status change messages for a given component. 

^0 A component may not receive AQ messages for several different 
reasons. The first reason is simply part of normal system 
operations, for example, when there are no messages in the 
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Hence, the comoonent wiil wait for a relevant message to be 
issued. The second reason that a component may not receive 
messages indicates a potentially serious problem, e.g., that 
the AQP 112a has failed, and is not sending messages. The 
5 various core components 112 realize that the AQP 112a is 
operational as it receives either heartbeat messages or 
sequenced synchronization message traffic. If the components 
112 do not receive either of these messages, they may indicate 
to the system 100 that a potential problem with the AQP 112a 
10 exists. 

An example of the function of the AQP 112a will be described 
with reference to Figure 5. The AQP 112a receives an AQ 
message from the database 111. The AQP 112a processes the 
message by converting it into RV format. As seen in Figure 5, 

15 a consuming component 112x receives data messages 1, 2, and 4. 
As will be appreciated by those skilled in the art, component 
112x realizes that an interruption in the data stream has 
occurred- The consuming component 112x issues or transmits a 
message 3 missing signal to the AQP 112a. In response, the 

20 AQP 112a sifts back through the data stream to find and 

reissue the message number 3 to the core RV ring. The missing 
message 3 is transmitted through the core RV ring and is 
consumed by component 112x. 

The operation of the AQP 112a is further described with 
25 reference to Figure 6. The AQP 112a transmits four messages 

as in the last example and they are each successfully received 
by the consuming component 112x. In the example, the four 
messages are followed by a period of time where no 
synchronization messages are sent that are applicable to the 
30 consuming component. Hence, the component 112x does not 

receive any messages- The AQP L12a sends "heartbeat" messages 
so that the component knows that the AQP 112a is still 
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has the same sequence number as the last synchronization 
message . 

PR Replicator 

The DR Replicator ("DRR") 112b, shown in Figure 3, is a core 
5 component that runs in the active core domain on a server in 

each of data centers 110 and 120. The DRR 112b ensures that a 
duplicate image of database 121 resides in data center 110, 
and a duplicate image of database 111 resides in the data 
center 120. Preferably, database replication occurs in real- 
10 time. 

Databases 111 and 121 are repositories for information 
pertaining to all system activity, including books, trades, 
orders, order creation and order disposition (e.g., cancel, 
expiration and/or execution). Data bases 111 and 121 could 

15 also contain information regarding clients, trade history, and 
market activity, for example. Preferably, database 111 
contains infoiniiation specific to a market located in an area 
associated with data center 110. Likewise, database 121 
preferably contains information specific to a market located 

20 in an area associated with data center 120. 

Real-time replication ensures that a current replica of each 
database is maintained in a geographically separate location 
in the event that data center 110 or 120 is not available for 
service. By maintaining a geographically separate copy of 

25 each marketplace's database, system recovery is ensured in the 
event of a failure, e.g., the original database is destroyed 
or is otherwise unavailable. One purpose of maintaining 
duplicate databases is to ensure that records of all trades 
made up to the failure are safely recorded so clearing and 

^0 settlement can be assured. In a failure scenario, the 
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database to facilitate clearing and settlement or to resume 
trading activity for the alternate market. In the Figure 2b 
arrangement, databases 111 and 121 within each data center 110 
and 120, respectively are redundant as well. That is to say 
5 that each data center 110 or 120 has two identical databases 

111 one residing on each server. Within data centers 110 and 

120, database replication between connected servers (i.e., 
between servers 110a and 110b, or between servers 120a and 
120b) is preferably facilitated via Oracle, Inc.'s Parallel 
10 Server technology, which is part of the Oracle 8 software 

system. As will be appreciated by those skilled in the art, 
any other software platform which allows duplicate replication 
between servers would be acceptable for this process- 

Both data center's 110 and 120 preferably have identical copies 
15 of the local and the geographic separate data center's 

database. For example, servers 110a and 110b each have a copy 
of database 121. Similarly, each of servers liOa and 120b 
maintain a copy of database 111 and database 121, Typically, 
only one instance of the DRR 112b runs within a given data 
20 center 110 or 120, The DRR 112b receives an AQ message stream 

generated by the database associated with the server in the 

t, 

other data center. For example, the DRR 112b in the data 
center 110 receives an AQ stream generated by database 121 in 
the data center 120. The DRR 112b receives and processes data 
25 center's 120 stream so that it can save data center's 120 
database 121 within its own data center 110. 

An example of off site replication is shown in Figure 7, As 
seen in Figure 7, the AQP 112a translates rhe data stream into 
an RV message, which is relayed to the core RV ring. The core 
30 RV ring provides the messages to component 112x and to the 

database 111. The database 111 issues an AQ synchronization 
stream to the AQP 112a and to the DRR 122b of data center 
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associated with the data center 110a in the database 127. As 
will be appreciated by those skilled in the art, the database 
127 can be physically housed in either the core components 112 
domain or in the database ill domain itself. At this time, 
the server 110a can also transfer an image or replica copy of 
the database 111 to the second server 110b for backup storage. 
Data center 120a also transfers a duplicate of its trading 
market through the database 121 to the DRR 112b. A real-time 
image of the market associated with the data center 120a is 
stored in database 117. 

As previously mentioned, a single instance of the DRR 112b 
runs in each data center 110 or 120. Should this instance 
fail, recovery can be facilitated by manual intervention or 
recovery software that restarts the failed instance or starts 
a new instance. During the period that the DRR 112b is out of 
service, the database . Ill (or an AQ generating component 
resident in the database 111)" builds a queue to store all 
messages that are to be consumed by the failed replicator. 
Software provided by Oracle, Inc., preferably Oy'acle AQ, can 
assist in delivering the queued messages once a new instance 
of the DRR 112B is started, for example. The DRR 112b is 
started and configured by the master control process,* 
discussed below, when the system is started. 

Master Control Process 

The master control process ("MCP") 119, shown in Figure 8, is 
a component that runs in each gateway domain and core 
component domain of each server located in data centers 110 
and 120. In the Figure 2b embodiment, two instances of the 
MCP run on each server. The MCP 119 is responsible for 
starting and configuring the componeg^t^^. running in a given 
MCP ' s 119 server domain. For example, v/ith reference to 
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respoasible for starting and coafiguring each component in 
that domain, Simiiarl/, the MCP 119 in the gateway 113 domain 
is responsible for starting and configuring that particular 
gateway 113. The, MCP 119 also provides system administration 
5 functionality, including monitoring the core and gateway 
components status as well as facilitating user command 
options. The MCP 119 also supports the system's 100 
resiliency functions- The MCP 119 component has four main 
functional units, including a MCP unit, a mcp config manager, 
10 a mcp_cfg editor, and a MCP monitor. 

The MCP unit is the processing center of the MCP 119 
component. The MCP unit manages and monitors the components 
running in its particular domain. The MCP config manager 
supplies all of the MCPs 119 within a data center with a 

15 centralized configuration information repository. The MCP 
config manager enables administration to be more efficient, 
since all MCPs 119 can utilize the single source of 
configuration information. Without this arrangement, each MCP 
119 would require a local configuration file, which would have 

20 to be administered. As seen in Figure 8, the MCP config 

manager can be remotely located (e,g., the MCP config manager 
does not have to be on a server or in a data .center 110 or 
120) . 

The mcp cfg editor provides an administrative interface to 
25 edit the configuration information supplied by the MCP config 
manager. Like the MCP config manager, the mcp__cfg editor can 
be remotely located, as shown in Figure 8. The MCP monitor 
provides a monitoring and command interface to the MCPs 119 
for administrative purposes.' The MCP monitor can also be 
30 remotely located. The MCP monitor is the primary interface 

for monitoring and controlling components that run in a given 
MCP's 119 domain. The MCP monitor provides status 
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execute a commands), as well as commands for issuing text 
space. The MCP monitor can display the processing status for 
each component in all MCP managed server domains. The MC? 
monitor is used to manually control the components running in 
a given domain- As shown in Figure 8, each of the MCP modules 
are connected via an RV ring. 

In the Figure 2b embodiment, the core and gateway domains 
necessary to run the system 100 can reside on one server or ■ 
they can be split across both servers in a particular data 
center 110 or 120, In Figure 9, the "active" core domain runs 
on server 110b and the "active" database and gateway domains 
run on server 110a for example. Splitting the domains across 
two servers may be an efficient way to share resources and to 
ensure efficient redundancy between linked servers r for 
example. The MCP 119 designates which domains are to be used 
as active domains in start-up scripts executed after a 
domain's operating system boots. If a domain is to be 
utilized to run the system, the script will start an MCP 119 
instance, which will in turn start and configure the 
components within its domain. 

The MCP 119 configures a domain based on system information, 
including database connection information, RV connectivity 
information, identification of shared libraries, the 
Persistence model being used, how many instances of a given 
component should be started (e.g., for multi-instance 
components like the Book Manager 112c), etc. A Persistence 
model can relate to the Power-Tier product and/or the system's 
100 memory object relational database, for example - 

A system startup and configuration, and the MCP ' s 119 role in 
the startup process, is now described. First, servers 110a, 
110b, 120a and 120b are powered up and the operating system in 
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MC? 119 instance in each domain is started. The startup 
scripts determine which MCPs 119 should start their 
components, and which should not. MCPs 119 that do not start 
their components remain operational in order to be available 
5 to start their components in the event the corresponding 

"active" domain fails. These MCPs 119 that are instructed to 
start their components broadcast a configuration request 
message via RV. This message is consumed by the mcp config 
manager. If an mcp config manager is running, the mcp config 

10 manager provides the MCP 119 with all configuration 

• instructions necessary to start the components for which it is 
responsible. If MCPs 119 do not find an mcp config manager, 
the MCPs 119 can use a local copy of the configuration 
information used when the system was last started. Each MCP 

15 119 automatically creates this file when it starts the 

components in its domain. The MCP 119 polls each component to 
determine its status. This "status" information is then 
broadcast via RV messaging to listening MCP Monitors. 

As previously discussed the MCP 119 plays a central role in 
20. system resiliency functionality. Before discussing the MCP ' s 
119 role in system resiliency, however, the following points 
are noted. First, the domains necessary to run the system 100 
can reside on one server or they can be split across both 
servers in a data center, as previously discussed. From a 
2 5 resiliency perspective, this is important because the system 
preferably does not utilize a traditional "hot" or "cold" 
standby model where a host computer is actively processing 
while a backup host computer waits to go live in the event 
that the active host fails. In the Figure 2b embodiment, each 
30 active domain in the system has a backup domain on the other 
server in a given data center that is available to take over 
processing should a problem arise in the operation of the 
comoonents in an active domain. Second, if a component fails 
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However, if nhe component can not be restarted, manual 
intervention may be necessary to solve the problem, either by 
fixing the failed component so it will restart or by starting 
the backup domain. Third, automatic domain-level failcver is 
5' supported. For example, if a domain fails (e.g., a hardware 
or operating system failure causes a failure), the MCP 119 
running in the backup domain on the other server will 
automatically start the components necessary to replace those 
in the failed domain. 

10 If. the MCP 119 detects that a componen-t has failed, it 

automatically attempts to restart the component (e.g., makes 
five attempts over a three minute period). As will be 
appreciated, the MCP 119 can be configured to make any number 
of attempts over any given time period. 

15 Domain failure can occur due to a hardware or operating system 
problem. The MCP 119 facilitates automatic failover in the 
backup domain of the adjacent server in the event that the 
active domain fails. For example, referring toy^ Figure 9, if 
the core components of server 110b failed, the MCP 119 

20 automatically converts failover to the core component domain 

of server 110a. The MCP ' s 119 role in system failure is j 
further described with reference to Figure 10. In Figure 10, 
server 110a houses the active database 111 and gateway 113, 
while server 110b houses the active core components 112. As 

25 shown an MCP 119 instance resides in all core component 112 
and gateway 111 domains. Each MCP 119 instance exchanges 
"heartbeats" with its counterpart MCP 119 via an RV line. For 
example, as seen in Figure 10, the MCP 119 resident in the 
gateway 111 domain of server 110a exchanges a heartbeat with a 

30 counterpart MCP 119 resident in the gateway domain of server 
ilOa. 
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In a preferred embodiment, cluster management software 
provides the system 100 with a procedure for system level 
status checking between the domains on each of the servers 
110a and 110b (or between servers 120a and 120b). Such 
5 cluster management software is developed by Sun Microsystem, 
Inc.'s, for example, including Sun's HA cluster management 
software. The HA technology provides a procedure to determine 
whether a problem is related to a domain failure. In one 
example, the core components remain operational, but a RV ring 

10 interrupts the MCP 119 heartbeat exchange. Without cluster 
.management software, the backup MCP 119 could erroneously 
conclude that the other MCP domain had failed, since it is no 
longer receiving heartbeats from that domain. If the HA 
indicates a system level problem, the MCP realizes that the 

15 problem is related to a network or application issue. The HA 
technology utilizes a private data channel for checking system 
status. Preferably, the data channel is a separate channel. 

If the HA software -relays a problem signal, the backup MCP 
automatically starts all of the components in the backup 

20 domain. In this manner the MCP 119 enables the system to 

resume processing without data loss in the event of a domain 
or server failure. In the event that a backup MCP fails to 
receive heartbeats from an active MCP, but does not detect a 
problem through the HA cluster management software, the backup 

25 MCP waits for a predetermined amount of time (e.g., five 

seconds or so) to see if the heartbeats resume, as would be 
the case if a network issue caused a momentary interruption. 
If the heartbeats are . still undetected, MCP 119 logs messages 
to indicate that manual intervention may be necessary to 

30 resolve the problem, as the problem could be caused by a 
network or application issue. 



The MCP 119 has various interfaces as discussed above. For 
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between MCP 119 instances in corresponding domains. 
Configuration information is broadcast via the RV channel to 
all components running in the same domain. Also, status 
messages are broadcast via RV to the MCP monitor. 

The MCP 119 also evaluates various incuts, for example, 
heartbeat messages received from the MCP 119 instances in a 
corresponding domain. The MCP 119 also receives as an input, 
configuration information received from the MCP config 
manager. Also, systems status information is received from 
th$ cluster management software, as previously discussed. 

Each MCP 119 is started by a boot script that executes when 
the domain's operating system boots. Manual control of a MCP 
119 is executed by using the MCP monitor, as previously 
discussed. The MCP 119 continuously runs under normal 
conditions and is not stopped unless the system is completely 
shut down. 

Book Manager 

The Book Manager 112c, shown in Figure 3 , is a core component 
that runs in the active core domain of a server locate'd in the 
data centers 110 and 120. Preferably, each book on the system 
100 has a corresponding Book Manager 112c instance. As 
discussed, a book in the system 100 can be defined as a set of 
bids and offers that compete with each other for the same 
instrument and settlement date in the same market type.' If 
bids or offers exist for multiple settlement dates for a 
single security, they are preferably maintair.ed in separate 
books , 

The Book Manager 112c is responsible for managing the system's 
100 order books. In particular, for passive orders, the Book 
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request is validated. A passive order is a firm bid/offer 
submitted by a trader with the intention of being displayed in 
a book for a particular instrument- Validating a request 
preferably includes verifying that the .requested instrument is 
5 found in database 111 (e.g,, a book exists) and the requested 
instrument is tradeable (e.g., the instrument has not 
expired) . The Book Manager 112c also ensures orders are 
sorted and/or listed appropriately within the book. 
Additional features of the Book Manager 112c include 

10 processing user requests to modify, suspend, or cancel passive 
orders. ' The Book Manager 112c also "expires" orders based on 
requests issued by the Expiry Manager 112e, discussed below. 
The Book Manager il2c can also be used to open and close a 
book according to the direction of the Rollover Manager 112f , 

15 discussed below. The Book Manager 112c also responds to 

suspend requests by the Bulk Request Manager 112g, discussed 
below. 

The system 100 provides several different subsets of 
information regarding each book (e.g., different book views). 

20 As will be appreciated by those skilled in the art, the 

subsets could be created and maintained by the Book Manager 
112c, or a book could be filtered (e.g., by the GUI, discussed 
below) to obtain desired subsets of information. A "Depth of 
Book" view for an instrument displays real-time information 

25 about its active orders. Examples of information displayed in 
the Depth of Book include; i) an ordered list of price/time 
sequenced bids and offers; ii) most recent trade information 
such as amount, price, time, hit/take, and indicator; and iii) 
settlement date information. Bids are preferably sequenced 

30 from highest to lowest price. Offers are preferably sequenced 
from lowest to highest (for currency price) or sequenced from 
highest to lov/est (for discount and yield orders). Orders are 
preferably sequenced from oldest to newest within a single 
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A "Top of Book'' view refers to information about the best bids 
and offers for a given security on the fixed inccne trading 
system. This view may also be referred to as the "market 
level/' since it gives a view of instruments and their 
associated top bids/offers level. The "Key Issues" view 
provides information which allows a user to create a 
customized view of the top of the book activity for a specific 
set of securities.. 

A status of a book describes the book's ability to accept 
orders. A book's status can be changed automatically by the 
system or by a broker using the B-Desk tools. Book statuses 
include: 1) open, which indicates that a book can accept 
orders for a security that it represents; 2) closed, which 
maicates that a book can not accept orders; 3) inactive, 
which indicates that a book is in maintenance mode; and 4) 
retired, which indicates that a settlement date for a book is 
past maturity. 

The system automatically assigns the book an "inactive" status 
during rollover. Rollover is a term used to describe the 
process of the system 100 calculating a new settlement date 
for the security. In a preferred embodiment, a broker (e.g., 
a party or entity that is neutral with respect to the outcome 
of a transaction) can change a book's status to "inactive" 
using various B-Desk tools, as discussed below. Changing a 
status to inactive is performed to prevent trading in a- given 
book (e.g-, to limit the security's availability for trading). 
As discussed, users or traders can submit orders such as a 
passive order with the intention of the order being displayed 
in the book. 

For aggressive orders, the Book Manager I12c effects trade 
executions. An aggressive order is an attempt to hit or lift 
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executed trade. Alternatively, an execution could include a 
"failed" order attempt and/or a failure notification. 
Assuming full execution, an executed passive order is removed 
from its respective book. An aggressive order is transient, 
meaning that it is either filled immediately against one or 
more passive orders, posts a residual amount as a passive 
order, or it fails. Executions are used by the Trade Manager 
112d to create real trades or ledger transfers, as discussed 
below. 

: A book keeps an order record for a given security and an 
associated settlement date. Each book on the system is 
managed by a single instance of Book Manager 112c. Therefore, 
there are multiple instances of Book Manager 112c in a given 
domain on a server, each managing a single book. Before the 
Book Manager 112c can administer a book, the book must exist 
on the system. The term "exist" means that objects have been 
created for the book, and that the system is aware of the 
book. However, the term "exist" does not necessarily imply 
that the book is available for order activity. For example, 
the status of a book could be closed, in which case the book 
is not available for order activity. To be available for 
orders, the book must have an "open" status. Open/closed , 
status is controlled by brokers using the B-Desk tools, as 
discussed below. Qrders other than "good til canceled" expire 
on a book closure (which is done using the B-Desk tools or the 
Rollover Manager 112f doing rollover) and requests for new 
orders are rejected until the relevant book is reopened. 

The Book Manager 112c interacts with several other core 
components. The Expiry Manager 112e consumes executions made 
by the Book Manager U2c. The Expiry Manager 112e consumes 
order messages to determine whether it must track expiree 
criteria. Gateways 113 and 123 consume all order output in 
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servers. "Appropriate'' in this instance could mean that the 
information is intended for a given application server's 
client, for example. 

The Expiry Manager 112e sends expiration requests to the Book 
5 Manager 112c, based on its processing of orders having expiry 
criteria. The Rollover Manager I12f sends cancellation 
requests to the Book Manager 112e when the Rollover Manager 
112f sets a book status to an inactive status during rollover. 
The Bulk Request Manager 112g sends suspended requests to the 
10 Book Manager 112c when the Bulk Request Manager 112g suspends 
all commands due to a system or user input - 

The Book Manager 112c is started and configured by the MCP 119 
automatically when the system is started. Manual control of 
the Book Manager 112c is obtained using the MCP monitor, as 
15 discussed above. The Book Manager 112c preferably runs 
continuously^ unless it is stopped to facilitate system 
maintenance. The various Book Manager 112c instances running 
on the servers respond to book status changes executed by the 
Rollover Manager 112f (e.g., going from an "open" status to an 

20 "inactive" status). The Book Manager 112c processes order 

I. 

requests such that it will reject order requests while the 
status of a book is inactive. However, an instance of the 
Book Manager's 112c remains active on the server even though 
the book's status is inactive. 

^5 Trade Manager 

The Trade Manager 112d, shown in Figure 3, is a core component 
that runs in the active core component domain of the data 
centers 110 and 120. The Trade Manager 112d is responsible 
for processing executions made by the Book Manager 112c. 
^0 Specifically, the Trade Manager 112d creates either "real 
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settle. A ledger transfer is a situation where a trade is 
executed, but the buyer and seller are from the same firm. A 
ledger transfer will not be settled, but the Trade Manager 
II 2d handles the necessary reporting to account for such a 
trade record. Preferably, with a ledger transfer, the Trade 
Manager 112d generates a notification to be relayed to the 
buyer and seller informing them that they are from the same 
firm. In the preferred embodiment, a commission is not charge 

, for a ledger transfer. The Trade Manager 112d also performs 
post trade calculations, such as coupons, accrued interest, 

• and fee calculations, etc. 

The Trade Manager 112d creates "tickets". A ticket is a 
record regarding trade details, and includes information about 
settlement, price, amount, instrument, etc. A client can 
manually print a ticket through the trader graphic user 
interface. A trader can use information from the ticket to be 
entered into his own trade capture system, for example. For 
the U.S. market, for example, a single ticket cannot exceed 
more than $50 million dollars. The $50 million dollar limit 
is the Federal Wire limit on fund transfers (all U.S. 
government fixed i.ncome transactions settle via the Federal 
Wire). When processing a U.S. trade, the Trade Manager 112d 
breaks the trades into blocks as necessary to ensure the 
Federal Wire requirements are met. The Trade Manager 112d 
also produces a "ticket set," which is a message that 
associates all of the individual tickets with the single 
execution that results in the ticket generation, in a "sweep 
the book" executian. involving n jardera^ as discusssji below, 
the Trade Manager generates n+1 tickets (e.g., 1 ticket for 
the aggressing order, and n tickets corresponding to, the n 
"swept" orders). For a European market, the Trade Manager 
112d is configured so as not to break-up executed trades, 
since there is currently no Federal Wire-like requirement in 
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The Trade Manager L12d interacts with several other core 
components. For example, the Back Office Adapter 112k, shown 
in Figure 3 consumes the tickets and ticket sets output from 
the Trade Manager 112d for settlement processing. Also, the 
Book Manager's 112c messages regarding executions are consumed 
by the Trade Manager 112d. 

The Trade Manager 112d is started and configured by the MCP 
119 automatically when the system is started- As with the 
other core components, manual control of the Trade Manager 
112d is "executed using the MCP monitor. Under normal 
conditions the Trade Manager 112d runs continuously except 
when it is stopped to facilitate system maintenance. 



Expiry Manager 

The Expiry Manager 112e, shown in Figure 3 , is a core 
component that runs in the active core domain of a server in 
both of the data centers 110 or 120, The Expiry Manager 112e 
is responsible for ensuring orders expire according to 
criteria submitted by the user. In particular, the Expiry 
Manager 112e captures order traffic being generated by the 
Book Manager 112c to determine whether an order submission 
specifies expiration criteria. For orders with expiration 
criteria, the Expiry Manager 112e calculates the expiration 
time, and sets a timer to signal when the expiration time 
occurs. The Expiry Manager 112e sends an expiration request 
message that is consumed and processed by the Book Manager 
112c when an order expires. Preferably, the Book Manager 112c 
then removes the order from the book. 



The Expiry Manager 112e interacts with various other core 
components. For example, the Expiry Manager's 112e "expire" 
rp.essages are received and processed by the Book Manager 112c, 
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are received and processed by the Expiry Manager 112e to 
determine whether expiration criteria must be tracked for a 
given order. Like the other core components the Expiry 
Manager 112e is started and configured by the MCP L19 
5 automatically when the system is started. Furthermore, manual 
control of the Expiry Manager 1129 is accomplished using the 
MCP monitor. Except for system maintenance, the Expiry 
Manager 112e continuously operates. 

Rollover Manager 

10 The Rollover Manager 112f, shown in Figure 3, is a core 

component that runs in the active core domain of a server at 
the data centers 110 and 120. The Rollover Manager 112f 
ensures that rollover occurs for all instruments available for 
trading in the system, ''Rollover" can be defined as the point 

15 at which a settlement date for a given security expires and a 
new settlement date is calculated. For example, if an 
instrument had a settlement date of T + 1 ("T" representing a 
trade date), there is a point in the trading day at which it 
is no longer possible to execute a trade and settle according 

2 0 to the T + 1 requirement. The Rollover Manager 112f ensures 
that no trades occur after this point, and that Rollover 
Manager 112f resets the settlement date of the instrument to 
the next applicable date available. 

In particular, the Rollover Manager 112f calculates the time 
25 at which trades for a given security can no longer be made. 

For this process, the Rollover Manager 112f changes the status 
of the book for the instrument to ''inactive." The status 
change signals the Book Manager 112c to cancel any outstanding 
orders in the book, if the book had been in open status. The 
30. Rollover Manager 112f then calculates the next settlement date 
for the security as discussed above. The Rollover Manager 
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The Rollover Manager 112f manages the status of eazh zcok. 
Status refers to a book's ability to accept orders. -\5 
discussed above, a book has at least three statuses: (i) open 
(i.e., accepting orders); (ii) closed (i.e., not accepting 
5 orders); and (iii) inactive (a status that is similar co 

closed in that the book is not accepting orders). '^Tr-active" 
is the status a book is given when it is associated vizh a 
security that is going through the rollover process. The. 
Rollover Manager 112f changes a book's status according to 
10 requests made by brokers associated with the system 100. 
These brokers use the B-Desk tools as discussed below to 
manipulate the statuses of the book. For example, at the 
start of each day, books must be "opened," or their statuses 
must, be changed from "closed" to "open." 

15 The Rollover Manager 112f is responsible for receiving 

requests from the B-Desk tools, validating the request, and 
changing a book's status as needed. When validating a request 
made by an affiliated broker to create a new book, the 
Rollover Manager 112f ensures that the requestedy^ instrument is 

20 available in the system's database 111, and that the security 
is authorized to trade on the system 100, for example. 

The Rollover Manager 112f interacts with the Book Manager 112c 
regarding a book status change. The Rollover Manager 112f 
verifies requests from the B-Desk tools during the process of 

25 book creation, for example. The Rollover Manager 112f is 

started and configured automatically by the MCP 119, shown in 
Figure 8, when the system is started. Manual control of the 
Rollover Manager 112f is accomplished using the MCP monitor. 
Except for system maintenance, the Rollover Manager 112f 

-0 operates continuously under normal conditions. 
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Bulk Renuest Manager 



10 



The Bulk Request Manager 112g, shown in Figure 3 , is a core 
component that runs in the active core domain of a server at 
data centers 110 or 120. The Bulk Request Manager 112g is 
responsible for processing bulk requests to cancel or susoend 
a user's order. Such a request can be generated by the system 
or by the user. For example, a system-issued suspend request 
occurs when gateway 113 loses contact with a client's 
application server. The gateway 113 immediately suspends the 
•client's orders to safeguard the client's position until 
communication is reestablished with the client. In a bulk 
cancel/suspend scenario, the Bulk Request Manager 112g 
determines which books contain orders affected by the bulk 
cancel/suspend request. The Bulk Request Manager 112g then 
15 communicates with the Book Manager 112c to cancel /suspend the 
appropriate orders. As discussed, the Book Manager 112c 
receives the cancel/suspend request resulting from the Bulk 
Request Manager 112g processing. The Bulk Request Manager 
H2g receives as input signals messages from the system 100 or 
20 from traders using the system 100. 



1, 



As with the other core components, the Bulk Request Manager 
H2g is started and configured by the MCP 119 automatically 
when the system is started. Manual control of the Bulk 
Request Manager 112g can be obtained using the MCP monitor. 
25 The Bulk Request Manager runs continuously under normal 

conditions, except when it is stopped to facilitate system 
maintenance . 



Session Manager 



30 



The Session Manager 112h, shown in Figure 3, is a core 
component that runs in the active core domain of a server at 
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responsible for managing user requests to access the system. 
In particular, the Session Manager 112h authenticates trader 
log in information and allows one trading session per log in. 

The Session Manager 112h is started and configured by the KCP 
5 119 automatically when the system is started. Manual control 
of the Session Manager 112h is accomplished using the KCP 
monitor. Under normal conditions, the Session Manager 112h 
runs continuously, except for when it is stopped for system 
maintenance * 

10 Terms and Conditions Adapter 

The Terms and Conditions Adapter 112i, shown in Figure 3, is a 
core component that runs in an active core domain of a server 
at data centers 110 and 120. The Terms and Conditions Adapter 
I12i provides an interface between the system 100 and the 

15 Terms and Conditions Database 136 (see Figure 1)- The Terms 
and Conditions Database 136 is the originating source for all 
fixed income security information for the system 100. 
Database 136 includes intormation such as CUSIP, ISIN, 
description data, terms and conditions, etc. An example of 

20 the database may be Reuters' Financial Data Model Fi:ied Income 
Product ("RFDMFI"). The components of the Terms and 
Conditions Adapter 112i and their associated functionality are 
discussed below. A receiver module receives terms and 
conditions updates and populates a database 13 9, preferably 

25 located in data center 120. In an alternative arrangement, 
database 139 resides in either data center 110 or 120, or 
both. Database 139 is referred to as an "intermediate" 
database. 

An updating process updates the Adapter's 1121 cache and the 
^0 system's core database 111' to reflect updates to the 
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conditions updates). Database 111 propagates updates to the 
core RV ring via the AQ synchronization stream. 
Alternatively, brokers associated with the system can use the 
B-Desk tools to select an instrument that should be available 
5 for trading from the intermediate database 139, and thereby 
update the system's core database 111 regarding that 
instrument, or the terms and conditions regarding the 
instrument. If the brokers have direct access as discussed 
above, the updating process could be eliminated. 

10 /a variety of other components are utilized to supply 

instrument information to the system 100 via the Terms and 
Conditions Adapter li2i- The process as shown in Figures 11a, 
lib, lie, and lid will now be described. Referring to Figure 
11a, database 136 supplies terms and conditions data to the - 

15 system 100. A dequeuing and converting module is provided to 
receive the data from the database 13 6 and to translate the 
stream into RV messages. For example, a product called 
"TIBAQ" from TIBCO, Inc. can be used for this purpose. RV 
messages are transmitted from the TIBAQ to a local RV ring. 

20 A Terms and Conditions Adapter 112i module, called a 

"tac_receiver , " for example, receives and stores messages m 
the intermediate database 139, located in the data center 110 
or 120. As will be appreciated, duplicate copies of the 
intermediate database 139 can be maintained on separate 

25 servers or in separate locations- For example, a redundant 
database for data center 120 can be maintained on either the 
data server 120a or 120b or in the data center 110. 

The intermediate database 139 contains the instruments 
available through the Terns and Conditions Database 136. The 
30 system 100 copies the data to the intermediate database 139 to 
avoid data corruption or compatibility problems with outside 
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was designed to use a specific data scheme that was then 
changed, the application would need -o be changed accordingly 
to accommodate the nev; scheme. Furthermore, by copying 
information from the outside database 13 6, the system can 
5 activate any fixed income instrument without having to involve 
an outside entity- Instruments are made available to the 
system 100 data centers 110 and 120 by a Terms and Conditions 
Adapter module, called, for example ''tac man." The tac man 
module listens on a local RV ring for messages pertaining to 

10 the market associated with the hosting data center (e.g., U.S. 
or. Europe). When a new instrument message- is received, tac 
man updates the Term and Conditions Adapter's cache 118, the 
database 111, and the AQ data stream. This is one way that a 
new instrument can be added to the system 100. Alternatively, 

15 the tac man module can be called into action manually by a 

system 100 administrator (or a broker), who is given the task 
of adding an instrument to the system. New instruments may be 
made available to the fixed income trading system by brokers 
creating books for new instruments via the B-Desk tools, for 

20 example. 

Figure 11c illustrates how an instrument is added manually to 
the system. A system 100 administrator 201 selects an 
instrument from the intermediate database 139 via a sqlplus 
module which generates a message on a tac RV ring via the 
25 TIBAQ 137. Sqlplus is a product from Oracle, which enables 
manipulation of database commands and database management. 
The tac man 202a and 202b modules in the data centers 110 and 
120 respectively, listen to the tac RV ring for messages 
pertaining to the market associated with the hosting data 
center. When a message is received, the tac man 202a and 202b 
update the Terms and Conditions Adapter's cache 118 and 
database 111, which in turn updates the core RV ring via the 
AQ synchronization stream as discussed above. 



n 
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Figure ild illustrates an example of a broker 210 directly 
adding an instrument to the system using the B-Desk tools. I 
this case, the B-Desk tools directly update the B-Desk 
application server's cache, which propagates the change to the 
5 database 111 or 121, and an AQ synchronization stream is 

issued. With this configuration, the tac man 202a module is 
not needed, since the instrument is added via the B-Desk 
application server within a data center. 

10 As with the other components, the Terms and Conditions Adapter 
■ 1121 outputs messages to the Rollover Manager 112f . The Back 
Office Adapter 112k, as discussed below, also consumes 
messages regarding security information for the Terms and 
Conditions Adapter 112i. The Terms and Conditions Adapter 

15 112i consumes messages generated by the intermediate database 
139 and messages distributed by the core's RV ring. The Terms 
and Conditions Adapter 112i is started and configured by the 
MCP 119 automatically when the system is started. Manual 
control of the Terms and Conditions Adapter 112i is 

20 accomplished using the MCP monitor. The Ter/ns and Conditions 
Adapter 112i runs continuously except when it is stopped to 
facilitate system maintenance. 

Client Database Adapter 

The Client Database Adapter 112 j, shown in Figure 3 , is a core 
2 5 component that runs in the active core domain of a server at 
data centers 110 and 120.. Ths Client Database Adapter in the 
data center 110 maintains client information regarding the 
market associated with the data center 110. Similarly, the 
client database adapter associated with the data center 120 
30 preferably maintains a client database corresponding to the 

local market. For example, if the data center 110 was located 
in New York, the Client Database Adapter preferably maintains 
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provides an interface between the system 100 and the Client 
Database 135. The Client Database 135 stores information 
regarding client accounts, including client organization, 
client information, user i.d., permission, organization level, 
5 company level, broker fee discount information, broker to 
client coverage, accounts/privileges, and credit limit 
settings, for example- 

A description regarding how client data is supplied via the 
Client Database Adapter 112 j will now be given with reference 

10 to. Figures 12a through 12c. The Client Database 135 publishes 
RV messages to a local RV ring via a client database publisher 
220. Like the AQP 112a, discussed above, the client database 
publisher 220 converts data messages into RV messages. 
Referring to Figure 12b, each Client Database Adapter 112 j and 

15 122 j subscribes to messages on the local client database RV 
ring, which was provided by a cdb publisher 220. The cdb 
publisher 220 converts information from the client database 
135 into RV format. Each client database adapter 112 j is 
preferably only interested in messages pertaining to clients- 

20 associated with that center's trading market place. For 

example, the Client Database Adapter 112j is interested in 
those messages pertaining to the market associated with the 
data center 110. Messages are received by modules (e.g., 
called "cdbman") 221a or 221b, which are responsible for 

25 processing and receiving messages from a client database 135 
local RV ring. When the cbdman 221a or 221b receives a. 
message it queues the Client Database Adapter 112j to 
simultaneously update its cache 118, database 111, and the AQ 
synchronization stream in a single ccmop.it operation. 
Preferably, client data is propagated through the system in 
this manner. 



The Trade Manager 112d consumes messages output from the 
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consumes messages output from the Client Database Adapter 
112 j. The Client Database Adapter 112 j consumes messages 
generated by the Client Database 135. The Client Database 
Adapter 112 j is started and configured by the MC? 119 
automatically when the system is started. Manual conurol of 
the cdb adapter is accomplished using the MCP monitor. The 
Client Database Adapter 112j runs continuously except when it 
is stopped to facilitate system maintenance. 

Back Office Adapter 

The Back Office Adapter 112k, shown in Figure 3, is a core 
component that runs in the active core domain of a server at 
data centers 110 and 120. The Back Office Adapter 112k 
listens for tickets or ticket sets from the Trade Manager 
112d, then transmits the tickets associated with each set in 
real-timp to an outside clearing entity 137. The BacV n£fice 
Adapter 112k manages ticket status. A ticket status indicates 
now a ticket is handled by an outside clearing entity, as 
discussed below. The Back Office Adapter 112k also logs 
trades to a database file. The file can be used for manually 
transferring trade information to the outside entity or 
clearing house, in the event of a real- time transmission 
failure . 

Figure 13a illustrates a schematic view of the Back Office 
Adapter 112k, and its relationship to the outside clearing 
entity 137, MQ manager 193 and monitoring interfaces 194, and 
195. The monitoring interfaces can be a terminal emulation 
194 of an IBM 5250 for example and/or a software tool called a 
ticket manager 195, v/hich is available for brokers through a 
broker desk. The ticket manager tool 195 runs on a 
workstation which gains access to ticket information through 
an application server.' The application server corwnunicates 
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tickets are successfully transferred to the outside eatity or 
cleariag entity 137 using the ticket manager tool 195, A 
TCP/IP link from the MQ manager 193 can be realized using a 
standard line, for example, a 56K line, DSL line, or T1/T3 
5 line or higher, as will be appreciated by those skilled in the 
art- Alternatively, the link can be maintained as part of a 
ESN (e.g., "external services network) 14. The IBM 5250 
emulation system can be used to monitor whether tickets are 
successfully transferred to the outside clearing entity 137. 

10 Figure I3b illustrates an example of the procedure to 

facilitate transmission of tickets to the outside clearing • 
entity 137, The Trade Manager 112d creates ticket sets 
associated with tickets executed by the Book Manager 112c, and 
outputs the ticket sets to the core RV ring in an exportable 

15 status. At this time the Trade Manager 112d also 

simultaneously updates . the cache, database 111 and issues an 
AQ synchronization data stream back to the core RV ring. 

The Back Office Adapter 112k processes the ticket sets in the 
exportable status, and sends the associated tickets to the 

^20 clearing entity 137 via the MQ manager 193. The Back Office 

Adapter 112k logs the ticket sets in a file. This file can be 
used for manual transfer to a clearing entity 137 in the event 
of a problem or as a quality insurance check, for example. 
The MQ manager 193 builds a queue of ticket messages and 

25 transmits the queue to the clearing entity 137 which 

preferably uses a MQ interface. Figure 13d illustrates the 
relationship between the MQ manager 193 and the clearing 
entity's 13 7 MQ manager 193. 

There are four possible ticket statuses associated with the 
-0 Back Office Adapter. These statuses include "exported," 

"accepted," "broken," and "pending." In the event that the MQ 
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exported. An exported status means that the Back Office 
Adapter II 2k will interpret that the ticket was transmitted 
successfully to the clearing entity 137. An exported status 
is not a confirmation from the clearing entity 13 7 that the 
ticket was received or accepted for processing. Even though a 
ticket status is exported, it is still possible that, the 
ticket was not transmitted, or that it was transmitted but not 
accepted for processing by the clearing entity 137. It is 
also possible that the clearing entity 137 received and 
accepted the ticket, but the confirmation message was not 
received back by the MQ manager 193. 



If a ticket is acknowledged by the clearing entity 137 as 
having been accepted for processing, the ticket status is 
changed to accepted. An accepted ticket status means that the 

15 clearing entity 137 has received and accepted the ticket for 

processing, and the Back Office Adapter 112k has received this 
acknowledgment. If the ticket does not export successfully, 
yet the MQ manager 193 reports that its connection to the 
clearing entity 13 7 is operational, the ticket status is 

20 changed to broken, A broken ticket status indicates a problem 
v/ith the ticket or a technical issue preventing the 
transmission of the ticket. If the ticket does not export 
successfully and the MQ manager 193 reports that its 
connection with the clearing entity 137 has been severed, the 

25 ticket status is changed to pending- A pending ticket status 
means that the MQ manager 193 will cease adding tickets to the 
queue. Tickets v/ill be maintained by the system until the 
problem is fixed. Any tickets already in the queue v^hen the 
problem begins will remain there and should be sent when the 

3 0 problem is fixed. Hence, a pending ticket status means that 
tickets are not being sent from the system to the clearing 
137. In this case the MQ manager 193 will attempt to 
reestablish the connection to the clearing entity 137 
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connection is reestablished, the MQ manager 193 will transmit 
the tickets in the queue automatically. As shown in Figure 
13e, the clearing entity 137 only messages back to the system 
100 when tickets are received and accepted for processing. 
5 The MQ manager 19 3 relays the acknowledgment signal to the 
Back Office Adapter 112k, The Back Office Adapter 112k 
preforms a commit operation which updates the cache, database 
111 and creates an AQ synchronization signal which is routed 
to the core RV ring, as shown in Figure 13e. As discussed 

10 above, the clearing entity 137 does not message back to the 

sys.tem if it receives a ticket but does not accept the ticket 
for processing. With reference to Figure 13a, the ticket 
monitoring tool 195 (e.g., a Broker Desk Tool) or the IBM 5250 
emulation system 19 4 can monitor the status of tickets being 

15 transferred to the clearing entity 137- 

The system 100 is equipped to handle problems associated with 
ticket transmission and acceptance between the system 100 and 
the clearing entity 137. For example, some ticket information 
may be problematic for the clearing entity to handle. This 
20 means that the clearing entity 137 received the trade but 

r 

could not process the trade. In this case, an ICI Impact 

t. 

module residing at the clearing entity 137 location places the 
ticket in its repair queue. From the system's perspective no 
error was reported back from the MQ manager 193. In this case 
25 the Back Office Adapter 112k executes or changes the ticket 
status to exported- An exported status will be shown in the 
ticket monitor 195. 

If the ticket was received by the clearing entity 137, but is 
problematic (e.g., needs intervention of some sort) it will be 
placed in the repair queue. For a broker monitoring the trade 
the fact that the status is not "accepted" can indicate that a 
problem exists. As discussed above, the ticket monitor can be 
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the impact system can be accessed via terminal emulation to 
repair the tickets in the repair queue. 

If the MQ manager's 193 link is inactive or otherwise 
unavailable, the MQ manager 193 will not signal an error and 
5 will continue to build its queue. In this situation, the 
connection between the MQ manager 193 and the clearing 
entity's 13 7 MQ manager is operational, but the process 
responsible for sending the tickets is not running correctly. 
Because an error is not reported back to the Back Office 

10 • Adapter 112k, the ticket status is exported. The clearing 
entity system will not have any record that the ticket was 
received. From a monitoring perspective the fact that the 
status is not marked as accepted indicates that the above 
described problems exist. In this case the Impact module (or 

15 system) can be accessed via terminal emulation to see if the 
tickets are in the repair queue, and if not in the queue, it 
can be determine that a problem exists with the communications 
link. 

If a ticket can not be transmitted, but there is nothing wrong 
20 with the clearing entity's 137 communication link, the MQ 

manager 193 issues an error back to the Back Office Adapter I 
112k. The Back Office Adapter 112k then changes the status of 
the ticket to broken. The ticket monitor as described above 
can be used to find "lost" tickets. If tickets cannot be 
25 transmitted because the connection between the MQ manager 193 
and the clearing entity 137 is dovm, the MQ manager 193 will 
issue an error to the back office. In this case the Back 
Office Adapter lL2k will mark the ticket as having a pending 
status. As in the above examples, the ticket manager 195 can 
30 be used to find tickets having a pending status. 

Th MQ manager 193 and the Back Office Adapter 112k interact 
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adds messages to the queues from tickets passed on by the Back 
Office Adapter 112k. The ticket monitor tool 195 reads ticket 
status messages from the B-Desk application server. Also, a 
log file contains ail trades for a given day (see Figure 13c). 
This file can be used to manually transfer trade information 
to the clearing entity 137 in the event that the transmission 
connection between the system and the clearing entity 13 7 
fails. As discussed, the Back Office Adapter 112k accepts 
trade ticket sets and associated messages generated by the 
Trade Manager 112d and messages distributed via the core RV 
ring. The Back Office Adapter 112k is started and configured 
by the MCP 119 automatically when the system is started- 
Manual control of the Back Office Adapter 112k is accomplished 
using the MCP monitor. The Back Office Adapter 112k runs 
continuously unless it is stopped to facilitate system 
maintenance . 

While the core components have been described with various 
individual functions, it will be appreciated by those skilled 
in the art that certain core components could be combined, or 
an individual core component could be configured to perforin 
the function of another core component. Such modif icat^-ions 
fall within the scope of the present invention. 

Gateways 

Gateway 113, shown in Figure 3, runs in its own domain on the 
server 110a located in the data center 110. As will be 
appreciated, the data center 120 has a gateway 12 3 operating 
on the server 12GA. Optionally, as shown in Figure 1, 
additional gateways 171 and 181 can be located in remote 
areas. Gatewavs 171 and 181 are placed t-n limit the number of 
connections required for client connections to the data center 
120. Without these remote gateways each client would need to 
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would be required without the gateways I7L and 181. However, 
gateways 171 and 181 provide service to multiple clients wxch 
less expensive local connections. In a preferred embodiment, 
the gateways 171 and 181 can be realized using a Sun 
Enterprise 6500/5500 server computer. The Sun Enterpr.se 
6500/5500 can run the Solaris 2.5 operating system, from Sun 
Microsystems. The Sun Enterprise 6500/5500 server is 
manufactured by Sun Microsystems, Inc. Documentation for the 
sun Enterprise 6500/5500 server can be obtained from Sun 
. Microsystems, or through the above-mentioned web site. 

one function of the gateways is to notify core components of 
order related transactions via a single commit operation, as 
discussed above, that simultaneously updates the gateways . 
113-s cache 118, database 111, and the synchronization stream. 
The gateways, also interface with and forward system processing 
results to application servers, for example, servers 151, 152, 
161, 162, 172, 173, 182, and 183. Gateways act a filters as 
they forward to a client only information that is applicable 
to that client or client site. 

Gateway 113 interacts with other donvaius within the server 
lioa. For example, a commit operation performed ^by a' gateway 
113 after a service request by an application server 

. . 1 .^^=.r^c, the system's database 111 and the 

simultaneously updates rne byi»v--u 

-u^^=.m ThP data is then consumed by a 
synchronization stream. THe aaca 

, particular core component that is interested in the data bexng 
transmitted. As inputs, the gateways receive information from 
application servers (e.g., 151, 151, 161, 162, etc.). In a 
preferred embodiment, the gateways 113 and 123 convert order 
request into objects representing the requests. The gateway 

3 113 listens to the core RV ring to pick, up RV messages 

resulting from core processings that need to be forwarded back 
to clients via the appropriate application server or connected 
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communication signals from both application servers 161, 162 
and the remote gateways 171 and 181. 

Gateways 113 and 123 are started and configured by the MCP 119 
automatically when the systems are started. The gateways L71 
5 and 181 in the remote locations 170 and 180, respectively, are 
configured in the same fashion. Manual control of the gateway 
113 is facilitated with the MCP monitor- Under normal 
conditions the gateway operates continuously unless it is 
stopped to facilitate system maintenance. 

10 Application Servers 

The application servers (e.g., 151, 152^ 161, and 162, etc.) 
runs at client sites 150 and 160. In a preferred embodiment, 
the application servers are Sun E450 servers. The Sun E450 
server is a product of Sun Microsystems, Inc. Each of the 
15 application servers run the Solaris 2,6 operating system, or 
an equivalent format. Documentation for the Sun E450 server 
can be obtained from Sun Microsystems , or through its above- 
mentioned web site. As shown in Figure 1, the application 

r ' . 

server resides outside of the client's firewall 153 or 163, 

t, 

2 0 respectively. Each application server is connected to its 
respective data center via a external service network 114. 
Preferably application servers run in pairs. Using two 
servers at each client location facilitates load balancing and 
resiliency. 

25 An application server accepts service requests from clients 
and updates its local cache. The application servers also 
forward service requests . ,frP.iT; c^ijLnts to the gateway 
associated with the requests. The application server also 
receives transmissions from the gateway and updates to its 

30 power tier cache. As will be appreciated by those skilled in 
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perform information "pushes'* to clients based on client 
interest. In this regard the application servers manages and 
tracks which clients are interested in certain information, 
and insures that the particular information is "pushed'* ro the 
5 appropriate client. As discussed, the application servers 

receive service requests from client/trader desktiops and sends 
the service requests through the external network 114 to the 
gateway 113. Preferably, the application servers start 
automatically when the system is started or initialized. 
10 Application severs preferably run indefinitely, or until a 
scheduled shutdown or operator instruction to facilitate 
system maintenance, for example. 

System Operation 

The following discussion provides a general overview of an 
15 operational aspect of the Fixed Income Trading System 100. 

Although the following discussion necessarily implies a linear 
progression of events, it will be appreciated , by those skilled 
in the art that the transactional nature of t^e system and the 
architecture make data updates and associated processing 
20 nearly instantaneously systemwide. 

The following discussion v;ill be given from the perspective of 
a trader associated with client site 150. As will be 
appreciated, however, the same or similar processing will 
occur from the client site 160 and data center 120. 
25 Furthermore, similar processing can occur from client sites 
170 and 180, with additional handling through gateway 171 or 
181. 

The function and operation of the trader GUI software is 
30 described below with reference to Figures 23-40. The 

preparation of the trader GUI software would be readily 
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this disclosure, preferably using Java Beans and the C++ 
prograirming language. As will be appreciated by those skilled 
in the art, Java Beans are software components that can be 
used in programing environments, like a visual prograinining 
5 environments. The trader GUI software runs' directly on top of 
the workstation's operating system. Given that the trader GUI 
software is preferably Java-based, the trader GUI software is 
platform-independent and will run on operating systems such as 
Windows 98, other windows-based operating systems, UNIX, etc. 

10 Traders can view "market activity" as well as executing 

transactions through the trader GUI. The GUI displays real- 
time market activity with respect to instruments posted on the 
system 100 . 

A log-in screen, as shown in Figure 23, is the first screen 
15 (e.g., dialog box) displayed to a trader upon launching the 
trader GUI software- Preferably, the trader sets up an 
account with the system offline (e.g. through a broker desk, 
or through an application process) and is issued a name and 
password at that time. Alternatively, an account set up 

process can be executed online to provide a user name and 

t. 

password for a trader. The system 100 (e.g., via the Session 
Manager 112h) validates a trader's user name and password by 
comparing the entered information against client information 
stored in the client database 135. Alternatively, user name 

25 and password information could be cached in the data center 
110 or in the respective application servers. The Session 
Manager li2h, compares the user name and password information 
to see if they match. If the information matches, the Session 
Manager 112h relays an authorization message through gateway 

^0 113 to. the GUI software on workstation 154. The message is 
transmitted from the gateway 113, through network 114 and 
application servers 151 and 152. If the authorization message 
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user name and password information do not match, the trader is 
denied access to the system LOO. A password can be configured 
to be "trader site" specific. For example, the password and 
user name could only be used from a specific trade site. 
Preferably, only one instance of the GUI per user password can 
be operational at one time. 

Upon entry to the system 100, the trader is presented with a 
main market screen 300, as shown in Figure 24, The main 
market screen includes a button bar 301, pull do^,m menus 302, 
•' and three primary book views 303, 304, and 305 . The main 
market screen 300 is fully configurable by the trader. For 
example, a trader can expand or compress the area of the 
displays or windows, and can determine which information is to 
be displayed through the views. In a preferred embodiment, 
the GUI uses a standardized color scheme to distinguish orders 
or requests on all display, screens and dialog boxes. In one 
preferred, embodiment, the following color convention is used: 
buys are represented by blue, sells are represented by pink, 
bids are represented by green, and offers are represented by 
yellow . 

1. 

The market level (or "top of book") view 303 is a summary 
level view (both of bid and offer) of the instruments within a 
given market. For example, as shown in Figure 24, the trader 
has selected "U.S. Treasury" from the market level pull-down 
menu 3 06 to be displayed. An example of a market level 
selection screen is shown in Figure 27. Other market views 
could include European markets and U.S. Notes /Bonds, for 
example. The trader can also invoke other main market windows 
300 to display types of instruments that the trader is 
particularly interested in, A trader can create a customized 
main market view by "clicking" on the market icon 312 in the 
button bar 301 in the recognized manner. The trader can 
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instruments to add to the new window 3 00. A tab is added to a 
tab^'section 307, "which allows a trader to toggle between 
selected windows. "Clicking" on a tab (e.g., U.S. Treasuries, 
Short Books, Euro-sovereign) on the customized views 307 

displays the selected view. The GUI software accesses 
information associated with a particular view and displays the 
relevant information through the workstation 154. For 
example, with the selected market view shown in Figure 24, a 
market level view for all U.S. Treasury "books" (e.g., all 
U.S. Treasury instruments on the system 100 by settlement 
date) are displayed, along with a configurable window that 
permits the user to select the columns they want to display 
(e.g*, bid, size, and offer) - 

One convention for U.S. Treasuries used by the system 100 and 
GUI software for "price" is dollars. Dollars are typically 
reflected in 1/8''*' of a. 32""*. As will be appreciated by those 
familiar with trading fixed income instruments, there are also 
"symbols" which have specific "price" implications. For 
example, a US Treasury lOyr, note with a 98.28+ price, equates 
to 98 per 100 dollars, plus 28 32"^ plus ^ of a 32"^ Hence, 
the " + " equates to a of a 3 2"^. Each security also has a 
market convention for amounts as reference is generally made 
to the total value of the security at maturity. In a 
preferred embodiment for U.S. Treasuries, an "amount" or 
"size" of 1 represents $1,000,000 par value at maturity. In 
the preferred embodiment with respect to U.S. Treasuries, a 
minimum amount increment is $1,000,000. As will be 
appreciated, the system can use other amount and price 
conventions depending on currency types, and can use different 
conventions for each instrument. 

With reference to Figure 24, instrument 303a ( "UST 6.000 
15Aug09") has a "best" bid price of 95-18+, with an amount 
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amount of 600 . Multiple orders at the "Top of Book" price are 
aggregated. Meaning, that if there are three separate bid 
orders at a price of 9 9-04, each with an amount of 20, the top 
of book display would be a bid at 99-04 with an amount of 60. 

5 The "Depth of Book" view 304 shows all orders (bids and 

offers, separately) that currently exist for each book within 
a market level. The depth of book 304 can be viewed by 
selecting a book from the top of the book or "key issues" 
views. For example, highlighting instrument 303a with a mouse 
10 . or a keystroke in the. standard manner, for example, would 
display all bids and offers associated with a book in the 
Depth of Book view 304. 

A benchmark or "Key Issues" view 305 is a window displayed- by 
the GUI software to show customized views of issues (e.g., 
15 benchmarks, sector, etc.)- The Key Issues view 305 is linked 
to specific market levels such that instrument information is 
displayed each time the linked market level appears in the top 
of book view. 



Order Submission * 

20 Order entry begins when a trader or user submits an order 
request from the trader desktop 154 to be posted in an 
instrument book, as shown in Figure 24. Traders populate 
instrument books by submitting orders, such as a bid request. 
To submit a bid, for example, a trader can "click" the bid 

25 button 310 from the main market view 300. Preferably, the 

trader is then presented with an "order entry" dialog box 320, 
as shown in Figure 25. Preferably, the information in the 
dialog box defaults to the instrument which is currently 
displayed in the Depth of Book view 304. For example, the 
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correspond wit:h the instrument displayed in the depth of book 
view 304, The bid price and amount can be changed via buttons 
323 and 324 , respectively. The order amount can be entered 
via the order amount area 325- The bid is submitted upon 
5 "clicking" the submit button 328. 

Preferably, the trader has an option to set a system wide 
safety key on the GUI that activates a "confirm" dialog box 
for each order that the trader submits. The safety options 
are set in a "preference dialog box" 315, as shown in Figure 

10 28^' The preference box 315 can be activated from the Edit 

Tool, pull-down menu 302, for example. The preference box 315 
also allows a trader to configure the Blotter 360, orders, 
market view, and to set default settings such as order size. 
The confirm box allows a trader to double check that the bid 

15 contains correct information prior to submission to the 
system. 

An offer order is submitted by clicking the offer button 311, 
which activates an offer entry dialog box 350, ajs shown in 
Figure 29. The order entry box 320 can be completed in the 
*20 same manner as was described above with respect to entering 
bids . ■ 

The order (bid/offer) is received by the application server 
151 or 152 at the client site 150. The application server 151 
or 152 updates its cache and delegates the request to the 

25 gateway 113 through the external network 114, as shown in 
Figures 14a and 14b. The gateway 113 creates the "object" 
necessary to process the order. For example, the object 
contains information regarding the order, routing information, 
and necessary processing information. Once the gateway 113 

3 0 has created the order object, it performs a commit operation 
that simultaneously updates its cache 113, database 111, and 
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A sequence number is assigned to each message in the 
synchronization stream as mentioned above. The 
synchronization stream is received by the AQ? LlZa component, 
which formats the messages into RV and broadcasts them into 
the core ring. With reference to Figure 14d, core components 
112 consume messages from the core RV ring by subscribing to 
particular message subjects. In the present example, the Book 
Manager 112c recognizes the order request message in the 
synchronization stream. The Book Manager 112c consumes the 
message and updates its cache, but the commit operation does 
not write through to the database 111, since the data stream 
generated by the gateway 113 will also reach the database 111. 
The Book Manager 112c processes the order request. If the 
entered information is "valid," (e.g., the information 
conforms to the instrument's requirements or parameters) the 
order's object state changes from an "order request" to an 
"order." For example, the book manager 112c could check to 
see if a minimum amount and/or maximum order size are met for 
a given book. If the parameters are not met, the trader could 
be notified to enter the correct information. Size and price 
parameters can be established when the book is created, for 
example . 

The Book Manager 112c also ensures that the new order is 
displayed and executed appropriately in a book. For example, 
for passive orders the sequence is price, time, then show. 
The best price order is always placed at the top of the book. 
At the same price, orders are sequenced on a first come, first 
served basis. In a preferred embodiment for the U.S. market, 
show amounts are executed before reserve amounts, as discussed 
below. In a preferred embodiment for the European market; 
orders with reserve amount have reserve amounts exhausted 
before shown amounts. Aggressive orders are processed on a 
first come, first serve basis. The Book Manager 112c could 
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"price, time" rule, as is the preferred embodiment for a 
European market. 

The Book Manager 112c then performs a commit operation that 
simultaneously updates the new information in the 3ook 
5 Manager's 112c cache, database 111, and synchronization 

stream, as shown in Figure 14e. With reference to Figure 14f , 
the Expiry Manager 112e and gateway 113 components receive the 
results of the -Book Manager 112c processing via the 
synchronization stream on the core RV ring. The Expiry 

10 Manager 112e consumes the order message, updates its cache 

(again in a non-write through commit operation) and determines 
whether expiration criteria was submitted- This example 
assumes that the order should expire in five minutes. An 
order expire time can be set using the "order expire" dialog 

15 area 327, shown in Figure 25, for example. The gateway 113 

receives the Book Manager 112c processing results and updates 
its own cache, as shown in Figure 14g. The gateway 113 then 
transmits the fresh book information to all applicable 
servers, as shown in Figure 14h. The gateway 113 also 

20 transmits client specific information about the order to the 

application server of the client that submitted the order. As 
will be appreciated by those skilled in the art, the 
application servers then push the information to the trader 
desktops (e.g., to the GUI software resident on the desktops) 

25 that have indicated interest in that particular book. 

If the expiration elapses on the example order (e.g., the five 
minutes has elapsed), the Expiry Manager 112e sends an 
expiration request to the Book Manager 112c. The Book Manager 
112c eliminates the order, updates the book, and the change is 
^0 disseminated systemwide a's described above with respect to a 
commit operation. 
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Order Acceptance 

A trader can "hit" a bid (e.g., accept a bid to buy) by 
activating (e.g., "clicking" the HIT button 313, shown in 
Figure 24. Upon clicking the Hit button 313, the trader is 
presented with a Hit Bid screen 330, as shown in Figure 26. 
Here, the trader can enter an amount to sell, price and 
minimum amount to sell criteria for the instrument. 
Preferably, the Hit Bid screen 330 defaults to the instrument 
displayed in the Depth of Book view 304. A bid is submitted 
.to the system when the trader clicks the sell button 333. 



A trader can "take" or "liff an offer (e.g., accept an offer 
to sell) by clicking or otherwise activating a "Buy" button 
3 12-. Upon clicking button 312, the trader is presented with a 
dialog box 340, shown in Figure 30. A trader can complete the 
15 take by filling out and submitting to the system relevant 

offer information, as discussed above with respect to "hitting 
a bid." 



Hitting a bid (or "taking" an offer) is an aggressive order. 
In a preferred embodiment, an aggressor pays a system 

20 commission on an executed trade. The commission c^n be 

determined based on the size of the transaction, a percentage 
of transactions . completed, or based on a fiat rate, for 
example. From a system perspective, commission calculations 
preferably are handled by the Trade Manager 11 2d, for example, 

2 5 when processing tickets. Commission information can be 

displayed to a trader through a trader blotter 360 (e.g.. 
Figures 36a-36c) , discussed below. 

From a system perspective, an object is created by the gateway 
113 when the trader "aggressor" enters an order request. The 
30 object is forwarded to the Book Manager 112c, as discussed 
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creates an order, and checks the respective instrument book to 
see if there exists one or more orders having the same 
criteria. If the aggressor order has the same criteria as one 
or more passive orders, an execution is made. "Same criteria" 
5 means that a hit /lift has the same price, amount and/or 

instrument ID, as a bid/offer, for exam.ple. The processing 
results of the execution by the Book Manager 112c are picked 
up by the Trade Manager 112d and gateway 113. The gateway 113 
transmits the effect of the execution to interested 

10 application servers systemwide. The Trade Manager 11 2d 

processes the execution data from the Book Manager 112c. The 
Trade Manager 112d performs post trade processing chores such 
as fee calculation, and creates tickets for settlement 
purposes. If this example occurs in the United States, each 

15 ticket has a $50 million dollar limit. In this case the Trade 
Manager 112d creates as many tickets as necessary to meet this 
requirement . 

The system 10 0 produces tickets • (e,g. , via the Trade Manager 
112d, as discussed above) so as to protect the client 
20 identity. A ticket reflects that the trade occurred with 
* system 100 itself, that is to say, the system 100 is the 

contra side for each trade, as discussed below. Hence^, a 
client remains anonymous. The Trade Manager 112d then commits 
the results to its cache, the database 111, and the 
25 synchronization stream. The synchronization traffic is 

recognized by the Back Office Adapter 112k. The Back Office 
Adapter 112k processes the ticket as discussed above with 
respect to the Back Office Adapter 112k. 

From a system perspective, an aggressive order is processed 
^0 according to established execution rules, as discussed above. 

The GUI software ensures that a trader has the order that they 
want to hit or lift visible for display (e.g., visible on the 



wo oi/5*>r>r>i 



PCT/USni/i)39S7 



When aggressing an order (e.g., hitting a bid)^ a price option 
can be selected on the dialogue box to indicate either a 
"Limit or Better" 333a or "Average or Better" 333b, as shown 
in Figure- 26, These options are used to determine which 
5 orders can be aggressed based on the price criteria set by the 
aggressor. A Limit or Better price option sets an absolute 
price limit (e.g., the system will not go beyond a specific 
price limit even if this means that the desired price and size 
cannot be achieved) . An Average or Better price option is an 
10 average limit (e.g., the system will aggress orders below 
specified price limits in order to get closer to a desired 
amount, provided that the process of overall or average price 
remains better than the limit) , 

In a preferred embodiment, an individual's own orders are 
15 highlighted on the display. The GUI software prevents a 

traders from aggressing orders that were submitted by himself. 
Alternatively, the system 100 could be configured so that the 
Book Manager 112c rejects an aggressive order on a passive 
order that a trader has submitted himself. This feature 
20 prevents a trader from artificially moving a market, for 
example. Also, in a preferred embodiment, passive orders 
aggressed by a user within the same organization will generate 
a "ledger transfer." A ledger transfer is a notational record 
where no fees are exchanged, in lieu of tickets requiring 
25 settlement. 

Reserve Order Handling 

System 100 preferably permits a trader to hold a transaction 
amount in "reserve," and that reserve amount is not displayed 
system-wide to other traders. For example, as shown in Figure 
30 25, a trader may reduce the "show" amount box 326 to show 10/ 
which would automatically keep 10 in reserve. All reserve 
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orders will be used to fill aggressive orders. However, the 
extent to which reserve amounts are used to fill such orders 
can vary, as explained further below. 

Preferably, shown orders are visible to all traders, while 
5 reserve orders are not shown to the market-at-large . A trader 
is able to view his own reserve amount through the GUI in a 
Depth of Book View 304, Holding a reserve amount enables 
traders to withhold from the market the full amount that the 
trader is willing to commit to the market. In one preferred 

10 embodiment, which for example can be used for European market 
trading, orders having a reserve amount are displayed 
systemwide with an "R" next to the shown amount. In a second 
preferred embodiment, which for example can be used for U.S. 
market trading, book views have no such indicator — and thus 

15 both the existence of reserve, and its amount, are withheld. 

As noted above, the extent to which the reserve are used to 
fill orders can vary. In one preferred embodiment for passive 
orders, the sequence is price, time, then show: shown amounts 
within a same price always execute before reserve amounts, and 
20 execution proceeds on a first come, first serve basis - 

This methodology of satisfying an order is used in the 
preferred embodiment in U.S. markets. Of course, best price 
always predominates- Thus, if two orders exist at different 
prices, the order will be satisfied at the best price for the 
25 aggressor, utilizing both shown and reserve amounts, before 
using the next best order to satisfy the aggressor. 

For example, as shown in Figure 31, four passive orders (Order 
Nos . 1-4) for an instrument (at the same price) are sequenced 
within a book as shown. The "show" column represents those 
-0 orders that are shown system wide to all traders. The 
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the market. The reserve amounts are preferably only displayed 
to the trader who submitted the order. If an aggressive order 
of 50 is raceived by the book manager 112c, Order No. I's 
shown amount (i.e., 5) is executed first, and then Order No. 
5 2's show amount (i.e., 25) is executed. Order Nos . 3 and 4 ' s 
shown amounts are then executed to fill an amount of 45 for 
the aggressive order. An amount of 5 is then executed from 
Order No. 1 reserve amount to fill the complete order. In -a 
preferred einbodiment for U.S. markets, a trader's selected 

10 shown amount, once exhausted, is automatically replaced (or 

"filled") from the reserve amount, if- any. "Filling" a shown 
amount will not result in a loss of any position, unless an 
order having a better price is received. Referred to as a 
"drip-rate," the reserve amounts automatically replace 

15 exhausted shown amounts, in one preferred embodiment. 

In another preferred embodiment, the sequence for execution is 
price, then time: orders with reserves amounts have the 
reserve amounts exhausted before shown amounts. Both shown 
and reserve amount are executed moving on to the next order at 
2 0 a next price. For passive orders at a same price, orders are 
displayed on a first come first served basis. This 
■ methodology of satisfying an order is used in the preferred ( 
embodiment in European markets . 



Modifying Orders 

25 A trader can use system 100 to modify his or her order before 
it is hit or taken. Shown orders may be decreased without 
consequence to an order's ranking {e.g., listed sequence) in a 
book. Reserve orders may be increased or decreased without 
consequence, and this rule for modifying an order is 

30 preferably employed for U.S. markets. However, increasing a 
shown order amount in the preferred embodiment for U.S. 
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orders at the same price below the order. Preferably, the 
Book Manager 112c generates a message to be relayed to a 
trader that an order's ranking may be jeopardized. 

Alternatively, the GUI software could evaluate an order and 
warn the trader, if needed, that his place in line for the 
respective book could be jeopardized. Of course, this is not 
an issue if the shown order is already last in line. An 
alternative option to increasing a shown amount is to enter a 
new order so that the original order amount retains its place 
in -line." 

In another preferred embodiment, increasing the overall size 
of an order, whether shown or reserve, results in loss of 
place in line. This rule for modifying an order is utilized 
by system 100 in European markets, where in satisfying an 
aggressor, reserve amounts are exhausted before moving on to 
the next order. OtheTOise, a trader can potentially 
manipulate the show/reserve amounts. | 



Sweeping the book is a function of system 100 that allows a 
trader to accept (e.g., hit/lift) multiple passive orders with 
a single operation. This function gives a trader the ability 
to- hit bids or take offerings from the top of the order book 
down to a specific bid below the top bid price, or up to a 
specific offering price to accomplish a specific size trade. 
The sweeping function promotes quick risk management 
decisions. P. trader can "sweep" the whole book, or part of 
the book, based on a maximum amount at a given price option. 
The orders are swept from the Depzh of Book view 3 04 by 
placing the cursor at an appropriate starting point for the 
sweep. A "tool tip" pop-up dialogue box can inform the trader 



Sweeping the Book 



wo l)l/5'K)r»l 



PCT/US()l/f)j»)S7 



on shown amounts. For example, as shown in Figure 32, if a 
trader wants to sweep offers associated with a given 
instrument, he activates a "sweep offers" 350 dialogue screen. 
Using dialog screen 350, the trader can select the amount of 
the instrument, offer price, and pricing scheme. With respect 
to the pricing scheme, a trader can select either a "Limit or 
Better" 353a or "Average or Better" 353b price option, as 
discussed about with respect to hitting a bid. Sweeping bids 
is achieved in the same manner. The sweeping-the-book 
function increases transaction speed and efficiency. 

From a system perspective, the Book Manager 112c receives and 
executes the "sweep" order based on the price and amount 
criteria in the order request. The executed orders are 
received by the Trade Manager 112d which creates tickets. A 
sweeping transaction is viewed as a single execution from the 
perspective of the .aggressor^ since the system 100 is the 
aggressor's counterpart. Hence, if n orders are swept, n+1 
tickets are created by the Ticket Manager 112d. 

In a preferred embodiment, the Book Manager 112c follows the 
same execution rules discussed above. Furthermore, in the 
preferred embodiment, the Book Manager 112c executes reserve 
amounts at a given price, after executing shown amounts, and 
before executing at a next price level. Also, in a preferred 
embodiment, when a trader sweeps the book, and as a result 
aggresses orders that are lower in the book than one or more 
of his own passive orders, the system will expire the trader's 
passive orders. 

Residual Posting 



A residual amount is defined as an unfilled balance of an 
aggressive order. Through the GUI, a trader has an option to 
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passive order in the subject instrument book. A trader can 
post a residual by "checking" a box in each of the hit/bid 
3 30, take offer 340 and "sweep" order (e.g., 350) dialogue 
boxes, as shown in Figures 26, 30 and 32, respectively. if a 
residual box is checked by the trader when entering the order, 
the system will post the residual at the aggressed-on price; 
meaning, that residual orders will be posted at the highest 
bid/lowest offer aggressed. In a preferred eiribodiment related 
to the U.S. market, residual amounts are posted entirely as 
shown amounts, with no reserve listed. In a preferred 
embodiment related to the European market, residual amounts 
are divided between a minimum size for a book show amount, and 
the remainder is stored as a reserve. 

Once a "Post Residual" box is checked, it preferably remains 
in effect until the trader removes the check from the box. 
Residual amounts less than a book's trade size minimum will be 
displayed if they are "Top of Book". Preferably, to aggress 
on these "below minium amount" orders, traders combine at 
least part of another passive order to meet trade size 
minimums. In a preferred embodiment, any residual amount less 
than 5 will be canceled automatically once it is no longer a 
top of book order - 

From a system perspective, the Book Manager 112c executes 
orders having a post residual authorization as discussed 
above. if an order contains such authorization, and a 
residual amount is realized from executing the order, the Book 
Manager 112c converts any residual amount into a passive order 
to be listed at the aggressed-on price in the respective book. 

Allowing a trader to post a residual provides efficiency to 
transactions, since a trader v;ill not have to reenter the 
unexecuted or unfilled amount. 
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Quick Hit/Quick Take 

Through the workstation GUI, a trader is provided with an 
option to execute a Quick Hit or Quick Take order, as shown in 
Figures 3 3 and 34, respectively. A quick hit or quick take 
5 box defaults to the settings that are selected in the 

preferences box 315, shown in Figure 28. As a result, a 
trader can increase transaction efficiency, by reducing order 
entry time. In essence, the Quick Hit/Quick Take function is 
a hit or take "shortcut." 

10 In a preferred embodiment, the Quick Hit or Quick Take dialog 
box can be activated, for example, by right clicking on an 
instrument listed in the Market Level view 303, Depth of Book 
view 304 or Floating Book view 370. Like a regular order, an 
object is created to represent a Quick Hit or Quick Take 

15 order. The Quick Hit or Quick Take request order is created 
and processed by the system (e.g., initially by the gateway 
113 and Book Manager 112c), as described above. 

Good-Until -Expiration 

t ' * 

Through the GUI, a trader can select expiration criteria for 
each passive order. As shown in Figures 25 and 29, a "Good 
Until'* drop down menu 327 or 357 , respectively, allows a 
trader to set an order's expiration time or date. For 
example, expiration criteria includes "Good Until Topped," 
"Good Until Time," "Good Until End of Day," and "Good Until 
25 Canceled." The default expiration setting for all orders is. 
Good Until End of Day. The Good Until End of Day option 
automatically expires orders which have not executed by 
trading day's end. An expired order is deleted from its 
respective book. 



wo 01/596^)! 



PCT/US0t/O3yS7 



When the Good-Until-Topped function is set, an order remains 
in a bock as long as the order is the best priced order in its 
respective book- A Good-Until-Topped order will remain active 
until another order is received that "tops" it. That is, the 
5 Good^Untii-Topped order expires, and is deleted from the 

respective book, as soon as an order having a better price is 
entered into the instrument book. In a preferred embodiment, 
the Good-Until-Topped order also expires at the end of a 
trading day. At that time, the order is treated as a Good- 
10 Until-End of Day, as discussed above. 

The Good-Until Time function allows a trader to enter a 
specific expiration time or duration (e.g., 15 minutes) for an 
order. For example. Figure 25 illustrates that the expiration 
time is set to be 3:41 p.m. If the bid is not hit by 3:41 
15 p.m. ^ it will expire. A Good-Until-Canceled expiration 

function .keeps the order in the system until it is canceled by 
a trader . This type of order will not expire at the end of a 
trading day, but will remain active until it is executed, or 
until it is canceled by the trader. 

20 From a system perspective, expiration settings are proqessed 
by the Expiring Manager 112e, in connection with the Book 
Manager 112c, as discussed above. 

Minimum Order Execution 

For aggressive orders (e.g., hits or takes), system 100 
25 preferably permits a trader to set a minimum transaction size 
required for an order execution. For example, a trader can 
"hit" passive bids (at a selected price option) for an amount 
of 275, but will accept a minimum transaction of 25 (see 
Figure 25, reference numbers 331 and 336 , for example). Thus, 
^0 if the order book contains one or more orders at the requested 
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order will be satisfied. However, if the order book does not 
contain orders ta the requested price totaling at least 25, 
then the aggressive order will not be satisfied. 

Pinging 

Using this minimum order execution feature, a trader can 
obtain information about the reserve amount for a given price 
option- A failed aggressive order of this type does not alter 
the other side (or sides). The other side will only be 
; notified if an execution occurs. At the same time, the Book 
Manager 112c preferably generates a failed notification, to be 
relayed to the trader, in the event that the minimum order 
amount cannot be filled. Thus, if an order is not filled, the 
aggressor is able to determine that the existing orders at the 
requested price do not have reserves at least equal to the 
minimum order amount less the shovm order amounts (at the 
requested price) . 

Au to- Aqg re s s / 

An inverted market occurs when a bid is submitted with a 
higher price than the best offer, or an offer is Submitted 
with a price that is less than the best bid price. To address 
an inverted market, the system 100 (e.g., the Book Manager 
112c in one preferred embodiment) preferably has an Auto- 
aggress feature that automatically converts the inverting 
passive order into an aggressive order. The newly converted 
aggressive order executes at the best bid/best offer on the 
syste.Ti. The svstem 100 automatically posts as a passive order 
in the respective book any residual amount at the specified 
price . 

In a oref erred embodimer.t , a trader that inverted the market 
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treated like an aggressive order. Also, in a preferred 
erabodiment , a passive order that inverts another passive order 
from the same trader is rejected by the system 100. 

Figure 35 is a flow diagram illustrating one preferred 
5 operation of the auto-aggress feature, as discussed above. In 
step SI, the book manager 112c receives passive orders 
requests (e.g., objects representing passive order requests), 
as discussed above. In step S2, the book manager I12c 
compares the passive order requests against current requests 

10 (if. any) in the book. The book manager 112c determines 

whether the passive order request inverts another passive 
order from the same trader (step S3). If the order request 
does invert another passive order from the same trader, the 
order request is rejected by the book manager 112c (step 34), 

15 The trader is notified that the order request has been 

rejected in step S5. If the passive order request does not 
invert another passive order from the same trader, the Book 
Manager 112c determines in step 36 whether the order request 
inverts the market. If the order does invert the market, the 

20 book manager 112c converts the order request into an 

It 

aggressive order in step S7, The Book Manager 112c then 
executes the order in step S8 as discussed above. The ^trader 
is notified of the executed order in step S9. If the order 
request does not invert the market, the book manager 112c 

25 processes the order and lists the order in the book (SIO). 
Preferably, the trader is then notified that the order has 
been entered into the book in step Sll. As an optional step, 
the system could notify (e.g., via a pop-up dialog box) the 
trader that he is about to invert the market, and verify 

'0 whether he wants his inverting passive order to be converted 
into an aggressive order. 
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Contingent trading is the process by which one can link a 
simultaneous execution on a buy and a sell transaction between 
two securities that are specified by the trader at a specific 
price or yield spread basis. The system 100 facilitates 
contingent trading through the GUI. This type of execution, 
which populates two order books, is contingent upon both price 
specifications being realized. 

Pegged trading is the ability of a trader to specify the price 
behavior of one security on the system 100 to the execution of 
the other security. For example, a trader may want to sell a 
30-year bond when the 10-year bond achieves a specific price 
bid. Again ^ the GUI notifies and the system 100 automatically 
makes these types of transactions when the specified criteria 
is reached. 

Pegged Bids and Offers 

A "pegged" market can be defined as a bid or offer on a 
specific security that uses another security or inciex as a 
benchmark. In a preferred embodiment, pegged trades are 
executed automatically by the system 100 when the current 
market on the system 100 reaches a "correct" price. The 
correct price can be determined by a new price in the pegged 
instrument, which generates a new bid or offer and/or 
determined by a "spread" between the security to be executed 
and the pegged instrument. 

Pegged bids or offers are dependent UDon the price of a bid or 
offer for an independent security. The price can be expressed 
as a "spread" to an independent instrument. In effect, every 
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rime rne Top-of-book bid or offer price on the independent 
instrument changes, so does the dependent bid or offer. 



The independent instrument for pegged bids and offers is 
preferably an instrument for which a book exists on the system 
iOO, However, i:: is possible that no bids or offers may be 
listed (or one active) in that book. In that case, the pegged 
order will not be active until an order exists to peg the 
price. If previously active, a pegged order will be 
automatically suspended if the independent top-of-book is not 
available. 



A trader specifies whether they are pegging to a Top of Book 
bid or a Top of Book offer. In comparison, contingent orders 
are preferably bid to bid(s) or offer to offer(s). 



An "inverted market" could occur as the result of a price 
revaluation on a pegged bid or offer. In these cases, the 
system 100 preferably does not show a bid price higher than 
the existing offer (conversely, a bid yield lower than the 
offer yield). Preferably, the system 100 automatically 
execute bids or offers under the following circumstances, 
particularly when sufficient liquidity exists at the Top-of- 
Book. First, a bid revalues such that its price is greater 
than the Top-of-book offer price plus commission. In other 
words, lifting the offer to buy and paying commission is more 
advantageous than bidding. In this case, price-improvement 
goes to a trader who originally entered the pegged order. 
Second, an offer revalues such that its price is less than the 
Top-of-book bid price minus commission. In other words, 
hitting the bid to sell at a price plus commission is more 
advantageous than offering. m this case, price-improvement 
goes to the person who entered the pegged order. 
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The following example is provided to further illustrate pegged 
trading . 

Example 1 - Peaa ed Trading 

Client XYZ enters a pegged bid for Security B of 10 million 
with the bid price pegged to Security A plus 1-027 . 1-027 
could also be expressed as 1 plus 2/32 plus 7/8 of 32 or 1 
plus 2 7/8 32nds. 

For this example. Client XYZ is assumed to be the only bidder 
for Security B, As discussed above, the "aggressor" 
preferably pays a commission for trades on the system 100. 
Furthermore, for this example, Client XYZ does not "go free" 
on commissions (i.e., XYZ always pays if it is the aggressor). 
For illustrative purposes only, XYZ pays less than 1/8 of a 
1/32"** commission. 



15 Event 1: Client XYZ enters the following bid: 

Security A Security B ^ 

Bid Offer SIZE Bid Offer SIZE 

98-10 98-124 10X20 99-127 99-134 10X50 

The Bid on Security B is calculated as 98-10 plus 1-027 = 
20 99.127. At this price, the bid on Security B would not be 
executed, because it is still lower than the best offer 
(99.134). In this example, SIZE = 10x50 means the bidder will 
take up to 10 Million Par at that price, the offerer will sell 
up to 20 Million Par at that price. 



25 



Event 2: The Top-of-3ook Bid Price on Security A changes to 
98-101 (e.g., the price of A goes up by 1/8 of a 1/32""*) 
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Security A Security B 

Bid Offer SIZE Bid Offer SIZE 

98- 101 98-123 10x20 99-13 99-134 10x50 

The result of the bid price on Security A changing is that the 
bid for Security B also changes (e.g., 99-127 plus 1/8 of 1/32 
= 99-13). However, there is still no trade executed because 

99- 13 is less than 99-134 by 1/2 of a 1/32'*^ 

Eve-nt J; The Top-of-Book Bid Price on Security A changes to 

98-105 (e.g., the Bid Price on A goes up by 1/2 of a 
1/32"^) . 



Security A Security B 

Bid Offer SIZE Bid Offer SIZE 

93-105 98-124 10x20 99-134 10x50 

The result of the bid price on Security A changing, is that 
the bid for Security B also changes (e.g., 99-130 plus 1/2 of 
1/32 = 99-134), However, this change still would not result 
in an automatic execution, since XYZ would pay more thaii the 
"spread" once corrutiission is calculated. XYZ would typically 
not consider itself an aggressor in this case. Hence, the 
trade will execute when the bid price is greater than or equal 
to the offer price, plus commission. In this case, the bid of 
99-134 is not greater than 99-134 , plus the commission. A 
situation where the bid price is equal to the offer price, and 
a trade can not execute, is referred to as a "locked market." 

Event 4: The Top-of-Book bid Price on Security A changes to 
98-106 (i.e. the Bid Price on A goes up by 1/8 of a 
1/32"'') 
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Security A 

Bid Offer SIZE 

93-106 93-124 10x20 

98-106 98-124 10x20 

98-106 98-124 10x20 



Security B 

Bid Offer SIZE 

99-135 99-134 10x50 

99-134 99-134 10x50 

99-134 x40 



The first line with numbers under Event 4 represents a 
calculated Bid/Offer, the second line represents prices used 
for execution, and the third line represents how the market 
will appear after the trade executes. 

As a result of the market bid price of A going to 98-106, 
XYZ's Bid Price for Security B goes to 99-135. The bid price 
(99-135) in this example is greater than the Offer price (99- 
134) plus coraraission (less than 1/8 of a 1/32"*"). In this 
case, XY2 would be willing to pay the offer price plus 
commission (since it is assumed that the commission will be 
less than 1/8 of a 1/32""*) - Accordingly, a system-initiated 
trade for a pegged buy order of 10 will execute at 99-134. As 
a result, XYZ will pay 99-134 plus a commission. The trader 
on the Offer side will be paid 99-134 and pay no commission. 
After the trade executes, the amount offered on B is reduced 
from 50 to 40. After the trade executes, there are not other 
bids for Security B (according to the assumptions ) - 
Preferably, only the final line under Event 4 would be 
displayed through system 100 as a result of the trade. 

As will be appreciated, in Event 3 the result was a locked 
market. If XYZ was a trader did not pay a commission per 
execution (i.e., they are allowed to "go free" or he pays a 
flat fee of some sort to the system), then the trade would 
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have executed. In other words, if the commission charged to 
XYZ were zero then the matched bid and offer would generate a 
transaction. In this case, the bid of 99-134 would be greater 
than or equal to the Offer of 99-134 plus the Commission of C 
( 99-134 = 99-134) - 

Also, if XYZ's commission rate is greater than 1/8 of 1/32, 
then the trade would still not execute in Event 4. In this 
case, the bid of 99-135 would be less than the offer of 99-134 
plus the commission. This would appear to create an 
"inrverted" market in which the bid price (99-135) was higher 
than the offer price (99-134). If this occurred, the system 
100 could either not display the 99-134 bid vs. 99-134 offer, 
or could deliver a message to the trader regarding the 
inverted market scenario which would explains why his bid is 
not being executed. 

As an alternative example, another commission paying trader, 
ABC, enters a bid of 99-134 for Security B. This creates a 
situation where Security B is "locked" for the same reasons it 
was locked in event 3. When Event 3 occurs, XYZ will just be 
one more bidder at 99-134, which can not execute. However, 
when event 4 occurs, an execution will take place and' XYZ will 
appear to obtain Security B at 99-134 despite the fact that 
ABC was there first with the same bid. XYZ's bid will be 
filled because in reality they are paying a higher price than 
the posted price due to the inclusion of the commission.- ABC 
will go without, an execution in this case. 

As will be readily apparent from the foregoing discussion, the 
Book Manager 112c preferably manages the pegged orders and 
performs trade executions, notifications and book management, 
as has been discussed in view of a pegged trade. 
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Contingent Bids and Offers 

Contingent orders are bids and offers that require two 
opposite trades to be executed simultaneously when the price 
differential between the two instruments reaches a specific 
5 level. 

A "single aggressor" scenario will be described- A single 
aggressor scenario involves an order being entered with a 
"spread" between a dependent and an independent security. 
Similar to Pegged Trades, an order is placed in the book of 
the dependent security and is revalued based on bids or Offers 
in the independent security's book. In addition to the 
spread, the trader specifies the amount of the independent 
security that should be accepted- If and v/hen the order in 
the dependent book is accepted, the system automatically 
accepts the order in the independent book. It is in the 
independent book where the user, due to being an aggressor, is 
obligated to pay a commission. 

The single aggressor model preferably requires that orders be 
placed such that bids are dependent upon other bi^s, and 
offers are dependent upon other offers. 

It is possible that no bids or offers may be active in the 
independent book or that the total of the orders in the book 
are not of sufficient size to fill the contingent order. In 
that case, the contingent order will not be active until an 
25 order exists to value the price of the order in the dependent 
book. 

An "inverted market" could occur as the result of a price 
revaluation on a contingent bid or offer. In this case, the 
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system preferably does not show a bid price higher than the 
existing offer (conversely, a bid yield lower than the offer 
yield). Like a case of pegged trades, it may be possible for 
the system to automatically execute bids or offers when this 
occurs . 



contingent orders differ from pegged orders in that they are 
preferably bid to bid(s) or offer to offer(s). 

The -following examples are provided to further illustrate 
contingent trading. In examples 1-3, a quote for a particular 
instrument x is referred to as Qx, where Qx is a body of 
information or function of three variables {Yx, Vx, Px} • In 
examples 1-3, Vx is a volume, par amount, or size of the bid 
or offer, Px is a dollar price, Yx is a yield 

Example 1 - (SINGLE AGGRESSOR) 

' In this example a pair of instruments "x" and "yj are at 
issue. A trader A acts as an aggressor for instrument y, 
after A's order on x has been acted upon aggressively by 
another trader B. For this example, y is the more liquid of 
the two instruments and will be the independent instrument 
within the pair. Instrument x is the instrument dependent 
upon Yy or Py of y, and Trader A will not be the aggressor in 
this security, but enters an order on x to buy or sell at a 
level dependant upon the Yy or Py of y. This order on Px and 
Py will be linked by some relationship determined by Trader A 
and this relationship can be expressed, for example,, as a 
dollar price difference, price ratio or yield spread between 
Bx and By. 

Vx and Vy will also be determined by Trader A and may or may 
not be ecual (face value on both sides), or could be 
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determined by a duration or risk equivalent calculation. This 
type of transaction can occur in the normal continuous trading 
environment. As an example, Trader A wants to sell x and buy 
y according to a specific relationship. 

Trader A would enter an order into the system 100 (e.g., 
through the trader GUI) to sell x with the requirement that 
the sell is "contingent" upon buying y. If the system 100 
detects an offer for y expressed as Qy, an offer for Qx is 
preferably automatically posted by the system for Trader A 
•according to the relationship designated by Px and Py. If 
this offer, QX, is lifted by a third party, the system will 
automatically and simultaneously lift the offer Qy on behalf 
of Trader A, before allowing, the transaction for the selling, 
by Trader A, of x. If y fails to transact, then x will fail to 
transact. The contingent trade will thus be transacted with 
Trader A acting as aggressor in By where he will be paying a 
commission . 

in this transaction, Trader A has sold x and bought y on a 
price contingent basis. If the offering on Py moves, the 
system 100 automatically adjusts Qx accordingly. If the 
offering on Py disappears or is withdrawn, the offering on Qx 
is automatically withdrawn. If the offering on Py is re- 
instated, the offering on Qx is automatically re-instated. If 
Vy is does not permit partial fills, Qx should have notice to 
this condition and can only be displayed within the . 
restrictions linking Vx and Vy. In a preferred embodiment, 
contingent trades are reflected as such through the trader 
Blotter 360 . An accumulation of separate trades as part of an 
overall contingent order may be treated as one order for 
commission purposes. 
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Example 2 (NO AGGRESSOR) 

In this contingent" trade example, a trader does not act as an 
aggressor on either side of the transaction, but merely enters 
his requirements as a condition linking Qx and Qy. This type 
of trade could be referred to as a 'package' or 'switch' 
trade. Typically, this type of trade would only be transacted 
if an aggressor had the exact opposite transaction to perform. 
When the aggressor enters the request to accept the Qx he 
would be given an indication that a simultaneous transaction 
at Qy must occur in order for his request to be processed. 
Preferably, the trader is prompted through the trader GUI to 
provide Qy to become a contra party for that transaction, or 
to decline to provide Qy. If the trader declines, the system 
100 could search for Qy and only process Qx if it was found. 
This type of trade would be entered in the Book Manager 112c 
as a function of Qx and Qy (e.g., "f{Qx,Qy}"). In one 
preferred embodiment, this type of contingent trade could be 
separately displayed as a non-aggressor quote driven 
contingent trade. 

In a typical book view, as shown in Figure 24, instruments x 
and y could be "flagged" as also appearing in a "contingent 
trading page" (e.g., a separate view or screen). Traders with 
an interest in either x or y could gather more information 
from viewing the contingent page. In this example, 
contingency may refer not only to price or yield conditions, 
but also to settlement and delivery conditions. For example, 
if one party does not deliver Bx then he does not have to 
accept delivery of By. 
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Kyample 3 ( DOUBLK AGGRESSOR) 



In this contingent trade example, a trader acts as an 
aggressor on both sides of the trade, and instructs the systerr. 
100 to "capture" posted bids and offers if they are available - 
For exaiuple, an initiating trader may want to sell x and buy y 
on a fixed yield spread which is a calculated function cf the. 
prices for these bonds, call it f{Px,Py>. In this example, 
the trader can enter his requirements into an order entry 
dialog box, or through the trade blotter 360, and the system 
automatically and continuously scans available quotes in the 
two relevant securities. If a bid (Px) and an offer (Py) 
which satisfy the conditions f{Px,Py} are found, the system 
automatically executes the transaction on both sides 
simultaneously and perform the contingent trade- 

For example, if Trader A is willing sell x at a 5 point spread 
to y, and y is offered at 4,95%, the system will float the 
order. The system will show an offering on x at 4.90%. If a 
third .party enters an order bid at a 4.90% on x, and y is 
still offered at 4-95%, the system 100 would buy y and hit the 
bid at 4.90%. The system 100 would then sell x for Trader A. 
The bidder receives their execution on x at their level of 
4.90%, and is preferably unaware (e.g., not notified) of the 
simultaneous transaction on y that has been system 100 
generated . 

As will be appreciated, the system 100 would only execute 
automatically if Vx and Vy were available in the relevant 
(duration weighted) amounts. This will usually mean that 
partial fills will need to be permitted on one side of the 
transaction or the other. This type of contingent trading is 
particularly useful when dealing with large numbers of 
securities over several screens in the system 100. On 
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available which would enable the contingent trades on the 
desired terms. In this case, the system 100 could notify a 
trader through the trader GUI of the availability of such a 
contingent trade. 



Example 4 — Linked Trading 



A linked transaction is a system 100 ability to simultaneously 
trade two or mor*:* securities linked to a spread, allowing tor 
the bid/offer spreads between th^ issues, In this example, 
the following information is available regarding Securities A 
and 



Security A Security B 

Market on System 100 Market on System 100 

98-09 X -10 99-11 X -12 

5-959 X 5.948 ' 5.941 x = 5.929 



Trader 1 wants to enter an order to sell security A, but 
linked to a transaction to buy security B. Trader 1 would like 
•to. execute this order regardless of the dollar price at a 
spread of .2 basis points. In this example, 1 basis point is 
equal to ten one hundredths of a percent (%). At the current 
market on the system 100, a sell on security A would execute 
at a yield price of 5.959, and a buy of security B would 
execute at a yield price of 5.929 which is a spread of 
(5.959-5.929) = .03. As will be appreciated, since a basis 
point is reflected in ten one hundredths, .03 is .3 basis 
points. Given the current market on the system 100 as shown. 
Trader 1 cannot execute his trade of a 0.2 basis points 
spread. 

In another example, the system 100, after the Trader 1 has 
entered his .2 basis point order to sell A and buy B, would ■ 
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generate a bid on Security B at 99-115 to yield 5 .939 for as 
long as the bid on security A is 93-09 to yield 5.959. The 
system 100 would also generate an offer on Security A of 98- 
096 to yield 5 .949 for as long as the offer on security B is 
99-12 to yield 5.929. 

In this example, three events are discussed. First, the 
trader buys security B at his system generated bid. If he 
buys security B at 99-115 the system sells security A at 98-09 
and pulls the offer on security A at 98-096, which results in 
the execution of his .2 basis points linked transaction. 
Second, the trader could sell Security A at his system 
generated offer. In this event, if he sells security A at 98- 
096 the system buys security B at '99-12 and pulls the bid on 
security B at 99-115, which results in the execution of his .2 
basis point linked transaction. Third, nothing happens and the 
trader's order floats as the market price changes on security 
A and security B. 

Negotiation ^ 

The GUI also allows a trader to indicate whether or not they 
are interested in negotiating the terms of a particular 
instrument. For example, as shown in Figure 25, a dialog box 
32 9 is provided to indicate that a trader is interested in 
negotiating the terms of the particular security. If an 
aggressing party is interested in a particular passive order, 
they can notify, through the system 100, the trader who 
entered the passive order, and conduct on-line or off-line 
negotiation. As will be appreciated by those skilled in the 
art, if the negotiation occurs on line, both parties can 
access a chat room or an instant message negotiation, for 
example . 
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Another aspect of negotiation is to allow a trader to 
privately and anonymously negotiate the terms of an execution. 
In a preferred embodiment, a trader activates a "negotiated 
order" dialog box through the trader GUI, to sends an order to 
5 any active bid or offer on the system- The negotiated order 
can include desired transaction criteria, such as order 
expiration time, piece specifications (minimum, maximum, 
specific size only), settlement date, etc. 

The target trader preferably can view and filter such private 
10 negotiated orders, through, for example, the blotter 360. To 
respond to a negotiated order, the target trader can Hit the 
"bid" of the negotiated order. In this case the target client 
would be considered the aggressor and would be responsible for 
any commission. Such a transaction could also result in a 
15 reduction in the size of the order placed by the target client 
by the amount traded. The target client preferably has the 
option of keeping the "public" order at the same amount or 
modifying the size of the order, for example. 

The target trader could also respond by sending the initiating 

t ■ ■ 

20 trader a new "negotiated order" with a lower price, for ^ 

example. The initiator trader could then respond as suggested 
above. The target trader could also respond by pulling their 
order, modifying the size of their order, or simply letting 
the order expire. 

25 hs will be appreciated, it is also possible that in the middle 
of the negotiation session that the target client's bid or 
offer could be executed. At that point the target trader is 
preferably notified by the system 100 that the subject order 
has been executed. 
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ADDITIONAL SYSTEM FEATURES 
Blotter 

The GUI provides a "blotter" 360, as shown in Figures 36a-36c, 
of all trades that the trader has executed. The blotter 360 
5 is a personalized work space that displays only the trader's 
own market activity. The blotter 3 60 filters information 
related to the trader, including, bids and offers, time (all 
trades within a specific time), price (all trades within a 
specified price), and amount (all trades with a specified 

10 amount), for example. From the button bar 301 (Figure 24), a 
trader can activate the blotter 360, as sho\m in Figures 36a 
through 36c. The blotter 360 can display top of book 
information, for example. From the blotter 360, a trader can 
view order information by activating tabs 361. Such 

15 information may include the trader's orders, including, 

executed, suspended, expired, canceled, and rejected orders. 
For example, as shown in Figure 36b, activating a "Rejected 
Request" tab indicates whether a trader has had any requests 
rejected. Also, as shown in Figure 36c, a trader can activate 

20 the "Suspended" tab to see whether any orders are currently 
suspended. Like the main screen 300, a trader can access a 
particular market or book through a button bar 362, A trader 
can also suspend or cancel orders from the blotter 360 screen. 

The blotter 3 60 serves as a customized filter in that it 
25 displays information pertaining to the trader's orders and 

transactions. As will be appreciated by those skilled in the 
art, the GQI gathers information (e.g., in one embodiment, 
from objects related to books, orders, requests, tickets, 
etc.) that is cached in the application servers, or that is 
20 pushed from a data center 110 or 120. The gathered 

information pertains to the trader's own market activity 
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Floating Book 

To free up desktop space, a trader can choose an instrument of 
interest (e.g., instrument 303a in Figure 24), and then 
activate a "floating book" 3 70 for that instrument by clicking 
on icon 311 on Figure 24. Figure 37 depicts a floating book 
for a particular instrument. A floating book 370 can be 
displayed independently of the main screen 300; meaning, the 
main screen 300 can be opened or minimized (or closed), while 
a floating book 370 remains open. Preferably, a trader can 
concurrently open many floating books, each representing 
separate instruments. 

A trader can submit hit, bid, offer, or take orders from the 
floating book 3 70 screen. A trader can also activate the 
Quick/Hit or Quick/take feature from the floating book 370 
screen by right "clicking" on a highlighted order and 
selecting the Quick/Hit or Quick/take from an activated drop 
down menu. 

Indicating Last Order 

k 

The GUI software displays the last trade that was executed for 
each book. As discussed, last trade information can be 
included in the Depth of Book view. For example, as shown in 
Figure 24, the last executed trade for the instrument shown in 
the Depth of Book view 304 is displayed in area 309. The last 
trade feature provides a trader v/ith real-time information 
regarding a particular instrument. 

From a system perspective, the book manager 112c can update a 
book when a trade is executed, as discussed above, by 
including last trade information. The last trade information 
can be distributed throughout the system (e.g., through a 
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discussed above). As will be appreciated by those skilled in 
the art, the GUI could then display the last trade 
information. Preferably, the last trade information can also 
be viewed from a floating book, as shown in Figure 37. 

Suspend >'^^nrel/M '^"^^i^'Y Orders 

Through the GUI, a trader can cancel, suspend, or modify 
orders that he has submitted. For example, a trader can 
. modify orders that he submitted from the Depth of Book view 
• 304 shown in Figure 24. A trader can modify an order's price, 
quantity, and reserve amount terms for a particular order. In 
a preferred embodiment, a trader's own orders are highlighted 
(e.g., are displayed in white or are bolded) on the various 
book views . A trader can modify his order by placing the . 
cursor on th'e target order, right "clicking", and selecting a 
"modify" option from the drop down menu. A dialog box (now 
shown) is activated to facilitate any changes to the order, 
orders can be modified from the blotter, in a similar manner. 
Preferably, a warning is issued to the trader if a size 
modification could potentially change the priority of the 
order. 

orders can also be suspended through the GUI. For example, as 
shown in Figure 24, the button bar 301 provides a "Suspend 
Orders" button. The Suspend button allows a trader to suspend 
a single order or suspend all orders that have been submitted 
to the system by that trader. Preferably, a "Suspend All- 
feature is invoked each time a client logs off the system or 
is inadvertently disconnected from the system. Orders that 
are suspended are preferably removed from a book. From a 
system perspective, the Book Manager 112c deletes or otherwise 
drops the order from a book and then updates the system 
through a comrr.it operation as discussed above. Preferably, 
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section of the trader's blotter 360 as shown in Figure 36c, 
and is stored locally on the trader's v;crkstation or in the 
application servers. Preferably^ each suspended order is 
individually reinstated by clicking, for example, on the order 
from the suspended blotter as shown in Figure 36c. 
Alternatively, groups of suspended or canceled orders may be 
reinstated in bulk. 

The system treats a reinstatement as a new order request. 
Consequently, the former suspended order will appear in the 
book as a new order. From a system perspective, reinstating a 
suspended order is handled as a new order request, as 
discussed above, A trader can also suspend all live orders 
from the blotter view 360. As shown in Figures 36a through 
36c, a suspend-live-orders dialog box 363 is provided for the 
trader's convenience. Clicking or otherwise activating the 
"O.K." button 364 will suspend all live orders, 

A trader can also cancel an order or all active. orders by 



clicking on the cancel live orders button as sl^vm in Figures 
36a through 36c. A trader can also cancel orders from the 

main view 300 as shown in Figure 2 4 by activating the "Cancel 

I. 

Orders" button on the button bar 301. Preferably, a trader is 
then presented with a Cancel Orders dialog box 380, as shown 
in Figure 38- The Cancel Orders box 380 permits a trader to 
cancel a particular instrument, or cancel all orders, bids or 
offers, for example. The trader can also select which market 
level to choose from. Like the suspend feature, order 
cancellations can be invoked on an individual order basis or 
in a bulk basis. Preferably, a bulk cancel feature is invoked 
for a particular book, whenever that book is "closed" (e.g., 
typically a book is closed at the end of a trading day) . From 
a system perspective, the Bulk Request Manager 112g receives 
and processes "suspend all" or ''cancel all" recuests. The 
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the Book Manager 112c, which in turn deletes or other.-/ise 
drops the orders from their respective books, as discussed 
above . 

A trader may only modify, cancel or suspend orders that 
originally were entered by that trader. Preferably, an 
exception to this rule is that if a broker is acting on behalf 
of a trader, then the broker will be able to perform any 
updates that the trader would have been able to perform had 
they logged off from the system as discussed below. The 
• features of system 100 that permit a broker to act on behalf 
of a trader are described in the "broker tools" section below. 



Notification 

Figure 39 illustrates an Execution Notification window. 
Through the Execution Notification window, the system 100 
notifies a trader when a trade has executed. In this way, a 
trader can be confident that his trades have executed. From a 
system perspective, the Book Manager 112c issues a trade 
execution to the Trade Manager 112d, and at the same time 
updates its cache and issue an AQ message to the system. This 
AQ message is relayed by a gateway to the trader's client 
site. As will.be appreciated by those skilled in the art, the 
GUI software displays this information to the trader. 



Multiple Depth o f T^nok Views 

Through the trader GUI, a trader can configure a window 
display to show multiple Depth of Book views, each for 
separate instruments. Preferably, a trader activates the 
multiple view screen through an option in the market 302 pull 
down menu shown in Figure 24. Figure 40 illustrates a window 
screen 390 having four depth of book viev/s concurrently 



wo 01/59661 



PCT/USI)1/IWS7 



several multiple view displays, which can be accessed through 
tabs 391. A multiple view tab is also added (preferably 
automatically) to the tab section 3 07 shown in Figure 24, A 
trader can access his blotter 360, market levels, and suspend 
or cancel orders through the multiple depth display 390, as 
shown in Figure 40. 

Fixed Income Ticker 

Through the GUI, a trader can activate a moving "ticker" 308 
that presents real-time information regarding instruments 
trading on the system 100. Preferably, a trader can customize 
the ticker to include those instrument information that the 
trader is interested in. In a preferred embodiment, a 
selected instrument (and related trading inforiRation) moves 
across the ticker area 308a. As will be appreciated by those 
skilled in the art, the GUI displays relevant information from 
an instrument's book for the moving ticker display, which 
object processing is preferably handled by the associated 
application server , 

Process Bar ^ 

The GUI also includes a process bar 310, as sho\^m in Figure 
24, that is accessible from the main screen 300. The process 
bar 310 provides a running list of all orders or requests 
submitted by the trader. The process bar 310 also provides a 
status indicator. The status indicator displays to the trader 
the status of each order. For example, when the Book Manager 
112c has received and processed an order (e.g., updated the 
relevant instrument book to include the order, or executed a 
trade), the "processed" status is display, as shown in Figure 
26. Other status indicators may include "accepted," 
"canceled," "suspended," "executed," and "rejected," for 
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another efficient means for a trader to monitor his trading 
activity . 

As will be appreciated by those' skilled in the art, from a 
system perspective, the GUI could maintain the process bar 310 
5 by adding an order to the list each time the trader submits a 
trade. The GUI could also monitor related instrument books to 
determine the status of respective orders. Alternatively, the 
GUI could monitor and update the status indicator from 
notifications received from the system 100 (e.g., 
10 - notifications generated and received from the Book Manager 
112c , etc . ) - 

Alternative Settl gn'^nt Dates 

A feature of system 100 is that the Book Manager 112c 
maintains a separate book for each different settlement date 
15 for a given instrument: This permits traders to choose which 
date for the instrument to submit bids and offers for, as 
discussed above. / 

Broker Tools 

I. 

System 100 preferably includes the capability for a third 
20 party, such as a brokerage firm, to monitor the market 

activity of traders on an approximate real-time basis, and 
also to act on behalf of certain traders in conducting market- 
activity . 

These activities are performed in system 100 by use of "broker 
25 tools," software that is installed on desk-top workstations 
that are a part of system 100. These broker tools produce a 
GUI on the broker workstations that broker personnel can 
interact with. For example, a broker firm can be provided 
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except workstations 175 would be provided with the broker 
tools software . Only workstations equipped with the broker 
tools software are able to perforin the functions unique to the 
broker tools, such as acting on behalf of a trader. Since 
workstations at the sites that are clients (e.g., traders) of 
the brokers, such as workstations 154, 160, 175 and 185 s.hown 
in Figure 1, will not typically be provided with the broker 
tools software, those workstations will not be able to perforin 
the activities unique to the brokers tools software. 

The function and operation of the broker tools software is 
described below with reference to Figures 41-50, which 
depict broker tools GUI screen displays. The preparation of 
the broker tools software would be readily apparent to a 
person of ordinary skill in the art, in view of this 
disclosure, preferably using Java beans and the C++ 
programming language. The broker tools software runs directly 
on top of the workstation's operating system. Given that the 
broker tools software is preferably Java-based, the broker 
tools software is platform-independent and will run on 
operating systems such as Windows 98, other Windows operating 
systems, UNIX, etc. , 

The broker tools software is launched by the user from his 
desktop workstation. Since the typical user will be a broker, 
the balance of this description of the broker tools software 
refers to the user as a "broker." After the broker tools 
software application is launched, a log-on screen (not shown) 
requests the broker to enter a user name and a password. 
Thereafter a broker desk tool bar having a plurality of icons 
is displayed on the workstation, as shown in Figure 41. This 
toolbar is used to launch particular broker tools applications 
by selecting the icon associated with each application, such 
as by mouse-clicking on the icon in the well-known manner. 
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In oarticular, clicking icon 10 of the broker desk toci bar 
launches the real time market monitor application, which 
displays the window shown in Figure 42. This window displays 
a scrolling list of the latest trading activity* Each row of 
5 information is for a different activity, and sets forth the 
time of the activity 10a, the instrument involved 10b, the 
type of activity 10c (whether it is a bid or offer for an 
instrument, or whether an instrument has been bought or sold), 
the price lOd, size of the order of transaction lOe;, the 
10 amount of any reserve lOf , the status lOg, the identity of the 
• client conducting the activity lOh, and settlement convention 
lOi (e.g., a trade date "T" + 1 day, etc.)- 

To allow the broker tools to monitor only particular aspects 
of the market, such as the activities of particular clients, 

15 the broker creates filters by clicking on the "File" option 

II, on the toolbar of the market monitor window, and selecting 
the "new filter" option" (not shown). This selection brings 
up a "create market monitor filter screen, shown in Figure 43, 
which contains three tabs. The first, the "orders/trades" tab 

20, 12, permits the broker to check the appropriate box so that 
the market monitor screen (Figure 42) displays only bids 
(12a), offers (12b)/ purchases (12c) or sales (12d), in 
accordance with the broker's selection. In addition, the 
broker can limit the display to activities of a certain size 

25 (12e), as well as apply further filtering criteria, depending 
upon the initial selections . 

In addition to the "orders/trades'* tab 12, the broker can also 
filter market activity based upon the instrument type* This 
is accomplished by clicking the "instruments'* tab 13. Doing 
30 so launches a screen as shown in Figure 44. The broker then 
clicks on the "sectors" bar 13a, which reveals a drop-down 
menu L3b, shov;n in Figure 45. This drop-down menu contains a 
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forth in Figure 45; for example, under "Instiaet," there is 
"Fixed Income," which is further divided into "US Markets," 
"US Government," and then a number of U.S. -issues, such as 
"UST Notes/Bonds." If this latter group is selected, then a 
5 list of instruments 13c is displayed, as shown in Figure 46, 
and the user can then select some or all of these instruments 
by clicking on the appropriate buttons 13d, thereby monitoring 
activities in the selected instruments. 

In addition to the filtering made available by selection of 
10 the- "orders/trades" tab and the "instruments" tab shown in 
Figure 43, further filtering is also availetble by selecting 
the "clients" tab 14. Selecting this tab causes the broker 
tools GUI to display the window shown in Figure 47, which 
provides a list of clients 14a. Selecting a particular client 
15 will then cause that client's trader personnel to be 

displayed, by user ID and user name. Particular clients 
and/or traders can then be selected by clicking on the 
appropriate buttons 14b, thereby resulting in the activities 
of only the selected clients and/or traders to be displayed in 
^20. the market monitor window shown in Figure 42. 

To the right of the market monitor button 10 in Figure Bl is 
user monitor button 20. Activating this button causes the 
broker tools application to display a list of trades, by user 
ID and user name (Figure 48). In the case where the broker 

25 tools are being used by a broker, the broker tools software is 
configured to display only those traders associated with the 
broker: i.e., his clients. Upon selection of a particular 
trader, the screen shown in Figure 49 is displayed, which is a 
market level view similar to that shown in Figure 24, except 

^0 that the order book will show the identity of the customers 

behind the bids and offers (21 and 22), and will also show any 
reserve behind each bid and offer (indicated parenthetically 
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b>-olcer to act: on behalf of the trader; thus, if the broker 
submits a bid or an offer, or hits or takes an order, that 
action will be registered as being undertaken on behalf of the 
selected trader. At the sa..e ti.e, the trader can continue to 
trade on his own behalf at his own workstation; utilization by 
the broker of the broker tools, to trade on the trader's 
behalf, does not disable the trader. 

in addition to being able to conduct transactions on the 
trader-s behalf, the broker tools software allows the broker 
■ to modify, cancel or suspend the trader orders, whether made 
by the trader, or on behalf of the trader by the broker. To 

select a specific order, right- 
do this, the broker can either sexec-c a 

click on it, and a menu will appear allowing the user to 
select canceling, suspending or modifying the order. 
Alternatively, all orders for that trader can be suspended or 
canceled, either by actuating the appropriate button 23, 24, 
on the button bar shown in Figure 49, or by right-clicking on 
the selected trader in the list of traders, which, as shown in 
Figure 50 allows the broker to cancel or suspend the orders 
for that selected trader. 

The broker tools also permit the broker to view tke selected , 
client's blotter. This is done by clicking on the blotter 
icon 25, shown in Figure 49, or by selecting a trader in the 
view Shown in Figure 48, and then clicking on the "view" label 
on the toolbar, which will reveal a "Blotter" drop-down 
selection. The broker can perform any activity in the blotter 
that is available to the trader, and the broker's activity 
will be reflected in the trader's own blotter. 

The broker tools also allows the user to perform maintenance 
functions. In particular, clicking on the instruments icon 
30, on the toolbar shown in Figure 41, bring up displays {not 
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system loo, as well as modify the characteristics of existing 
instruments. Also, clicking on icon 40 allows the broker tc 
preform book maintenance, and clicking on the icon 50 allows 
the broker to preform sector maintenance. Book maintenance 
5 allows a broker through a dialog box, or a series of dialog 
boxes, to created "books" for instruments within the system 
100. Book maintenance also allows a broker to open, close or 
deactivate a book. Sector maintenance is for maintaining 
sectors and creating new sectors . Sectors are broad 
LO categories for individual instruments. For example, a sector 
of U.S. Treasury Notes/Bonds could be 0-2 year, 2-5 year, 5-10 
years, and 10-30 year sectors. 

Supporting Network 

Figure 15 illustrates a simplified view of the network 

L5 supporting the system 100. In a preferred embodiment, the 
following networks are used to support -the fixed income 
trading system: ISN/PIN; admin LANs in the data jcenters 110 
and 120; ESN 114; and supporting networks such a.s 114a. The 
ESN, ISN and PIN networks are preferably TCP/IP based 

20 networks. As will be appreciated by those skilled in t^e art, 
any TCP/IP based network could be used by the system. Also, 
as will be appreciated by those skilled in the art, the 
network could include various routers, relays and switches to 
facilitate message distribution and system integrity. The PIN 

25 supports the system 100 by linking the data center 110 and 

data center 120 B-Desk trader desktop applications. With such 
a connection, a trader at a desktop application in location 
110 can view the local network, as well as the network in the 
location associated with the data center 120. B-desk tool 

''^ administrative functions can be exercised from a broker desk 
in various locations (e.g., in New York or London) with the 
preferred network connection. In a preferred embodiment, the 
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Terms and Conditions Database 136 by data centers UO and 120, 
and facilitates message traffic between each server in a given 
data center. For example, in the Figure 2b embodiment, the 
PIN facilitates communication between server 110a and 110b. 
With this type of interconnectivity , all system activity can 
be accessed and processed through each B-Desk location. The 
PIN also provides links to the ESN network including for the 
broker desk, for example, to use the B-Desk tools. 

AS will be appreciated by those skilled in the art, known 
• network protocols ensure that traffic automatically finds an 
alternative route in the event of a single router/switch or 
line failure. With the preferred connection discussed above, 
for example, if either B-desk is lost (e.g., in the event of a 
loss of a facility) , the other B-desk will continue to have 
connectability to both data centers and clients via the esn 
network. Furthermore if either data center is lost both B- 
Desk locations have connectability to the remaining data 
center. The resiliency .design of the system 100 provides 
support to ensure appropriate system response to a network 
failure. For example, if a router or switch that was 
associated with an applications server failed, the system 100 
would utilize the remaining application server. The PIN can 
be monitored by operational personnel using software such as 
Hewlett Packard's Open View and Network Node Manager, for 
example, or other similar software platforms. 

A3 will be appreciated by those skilled in the art, the admin 
LAN could support console access to each of the servers at 
each data center 110 and 120. Through the admin LAN, a system 
administrator could configure the network servers, administer 
the various domains, and perform other administrative tasks. 
In one preferred embodiment, each backup gateway 130 and 140 
is connected to its respective data center through a LAN. 
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The ESN network 114 supports the fixed ip.come trading system 
shown in Figure 15 by linking the components at data center 
110 and 120 with various sites. In remote locations or in 
either of the locations associated with data center 110 and 
5 120 the ESN network 114 can be fed (e.g., channeled) through 
existing or alternate networks such as network 114a (e.g., 
HPSN-NG, Reuter's High Performance Network-Next Generation). 
Like the PIN network, the ESN network 114 has numerous 
connection possibilities via the system switches and routers. 

10 As will be appreciated by those skilled in the art, standard 
network protocols ensure that traffic automatically finds an 
alternate route in the event of a single router, switch, or 
line failure. Like the PIN network the ESN network 114 can be 
monitored by operational personnel using software such as 

15 Hewlett Packard's Open View and Network Node Manager, for 
example, or any other similar software platform. The 
resiliency design of the system 100 provides support to ensure 
appropriate system response to a network failure. For 
example, if a router or switch that was associated with an 

20 application server failed, the fixed income trading system 
seamlessly utilizes the remaining application server. 

U.S. Clearing and Settlement ; 

Settlement for executed trades is facilitated in the United 
States through external agencies. Some of these agencies 

-5 include ICI, Government Securities Clearing Corporation 
(GSCC),' and the Chase Manhattan Bank. ICI is owned by 
Automated Data Processing, Inc., and handles post trading 
processing for settlement purposes. The ICI processing 
includes calculations such as end of money, accrued interest, 

-0 and commission calculation. 

ICI is a clearing entity 137 that the fixed incoT.e trading 
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receives fixed income transaction information in real-time via 
a direct link with the system 100. The Back Office Adapter 
112k is responsible for facilitating this data transfer. The 
Back Office Adapter 112k listens for tickets that have been 
produced by the Trade Manager 112d. Output from ICI may be 
forwarded to the Government Securities Clearing Corporation 
(GSCC) for further processing. Details regarding the ICI 
processing are provided below. 

GSCC is a corporation owned by a variety of major U.S. 
■ security firms. GSCC was formed to overcome the inefficiency 
of manual clearing processes and to mitigate the risks 
associated with a failure of a securities firm. For example, 
if Firm A failed, all other firms with which Firm A had traded 
with would be unable to collect the money for trades they had 
assumed were final. This type of failure could result in 
other firms being unable to settle their trades, possibly 
resulting in other firm's failure as well. 

GSCC mitigates this risk by becoming the counterparty to all 
transactions submitted to its netting service as explained 
below.' Clients of GSCC are called participants. These 
clients must meet a variety of financial criteria in order to 
become participants. GSCC offers two essential services. 
First, GSCC offers a "trade comparison." Trade comparison 
matches trade details of a two-sided trade to confirm that a 
trade has indeed taken place. When GSCC clients produce a 
trade, each side submits its trade details to GSCC 
electronically. The comparison process runs each night. If a 
given side matches that of another, the trade is the to have 
been compared, and GSCC produces reports for each client 
showing the comparison activity. .^^ost GSCC clients also 
utilize the "netting" services, explained below. 
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Netting is a process that calculates a firm's net position in 
each security trade for a given day. Netting is offered only 
to clients that have submitted their trades for trade 
comparison. For illustrative purposes, consider Firm A, which 
trades only one instrument all day. If Firm A buys and sells 
with numerous other firms, at day's end. Firm A and all other 
firms with v/hich it traded submit their sides to GSCC for 
comparison. Once the comparison process confirms that all 
trades have actually occurred, the netting process calculates 
Firm A's net position in the security it traded. It does this 
by -adding up all of the buys and all of the sells then 
calculating whether it has a positive (e.g., it will receive 
securities) or negative (e.g., it owes securities). As will 
be appreciated, this example is overly simplistic in that a 
firm is not likely to trade in only one security on a given 
day. However, the general process is the same regardless of 
how many securities a particular firm trades. 

Part of the netting service is that GSCC becomes each 
submitting firm's counterparty for settlement purposes. This 
means that once two sides of a trade are to be compared j. GSCC 
steps in and assumes the contraside for each submitting t^side 
for settlement. For example, Firm A and Firm B make a trade. 
Without GSCC, each firm would be exposed to the risk of the 
other firm failing to meet its settlement obligation. By 
having GSCC assume the contraside for settlement purposes, 
this risk is mitigated because it is highly unlikely that GSCC 
will default on any settlement obligation. The reason that 
this is true is that GSCC calculates a margin for each 
parcicipating firm based on its trading activity. This margin 
is calculated and collected daily. Therefore, if any firm 
proves unable to meet its settlement oblig^ation to GSCC, most 
of that obligation would already be deposited with GSCC. Any 
the amount not deposited with GSCC would be divided among all 
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of the GSCC clients. GSCC mitigates the systematic risk 
through diversification of settlement failure. 

Like comparison, netting is run in a batch mode in the early 
hours of the morning. When complete, reports are produced for 
5 submitting firms and net positions are reported to the 
clearing bank for settlement. 

When a trade occurs through the system 100, as described 
previously, the system 100 steps in to protect each sides' 
•identity by reporting itself as the contraside. For example, 

10 a case where Firm A and Firm B trade on the fixed income 

system is illustrated in Figure 16- Because the fixed income 
trading system 100 protects the identity of all trading 
clients, the system itself is considered the contraside from 
both Firm A's and Firm B's perspective. To settle a trade, 

15 Firm A and Firm B will report the trade to a clearing entity 
such as GSCC. Each submission will show the trading system 
100 as the contraside. The system 100, through the Back 
Office Adapter 112k, will also report the ti/ade to the 
clearing entity such as GSCC, via a clearing entity such as 

20 ICI, for example. The system 100 'will show (via the Trade 

Manager 11 2d generating tickets as such) one submission with a 
trade with Firm A, and a second submission will show a trade 
with Firm B. As shown in Figure 17a, the system 100 posts 
(via the Back Office Adapter 112k) to the clearing entity ICI 

25 137A a trade between itself and Firm A, and another -trade 

between itself and Firm B: ICI or a similar clearing entity 
137 then posts the transaction to a further clearing entity 
such as GSCC. Firm A and Firm B each posrs a trade between 
itself and the system 100. In this manner the trades are 

30 matched up while still protecting the identity of each firm- 
A clearing entity 137 such as GSCC runs a comparison process 
similar to the one illustrated with Figure 17b. As seen in 
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trade with the system buying from Firm A and a subraission (2) 
with the system selling to Firm B. As discussed, the 
submission could be a ticket created by the Trade Manager 
112d, and forwarded by the Back Office Adapter 112k. 

This information is submitted to a trading entity such as GSCC 
in the process described above with respect to Figure 17a. 
Firm A also issues a submission (I) indicating a sell from 
itself to the system 100. Similarly Firm B issues a 
submission (1) indicating a buy from itself from the system 
100,- The GSCC then compares the system's 100 buy submission 

(1) with Firm A's sell submission (1), The system's sell 
submission (2) is compared with the Firm's B buy submission 

(2) . 

When GSCC runs the netting process, the following results 
occur. First, the system 100 is "flat" because the system's 
buy/sell submissions cancel each other out. Firm A will "net 
long," since it owed money and must surrender the security. 
Firm B will "net short," since it must pay money to receive 
the security B, The next step involves an actual settlement, 
which is facilitated by a settlement organization such as 
Chase bank, as discussed below. 

The Chase bank provides the financial services necessary to 
settle transactions. In one example, the GSCC reports the 
netting results to Chase, which instructs Chase as to the 
day's transaction details. GSCC becomes the contraside to all 
transaction for settlement purposes. Under the example, GSCC 
would then tell Chase to expect to receive securities from 
Firm A and to receive payment from Firm B. Upon receipt. 
Chase transfers the money to Firm A's account and the 
securities to Fiirm B's account. 
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Non-U. 5. Clearinc and Se ttlement 

The following discussion details an embodiment where data 
center 120 is located in a European marker. Typically, 
settlement is facilitated in Europe through external agencies, 
5 such as CSDs (Central Securities Depositories); ICSDs 

(International Securities Depositories); and Settlement 
Agents . 

The International Securities Market Association (ISMA) is a 
self-regulatory industry body and trade association for the 

10 international securities market in Europe, ISMA's primary 

role is to issue rules and recommendations relating to trading 
and settlement practices in the international market. ISMA 
membership currently includes more than 700 member 
organizations from fifty countries. One of the ISMA's rules 

15 is that all European trades be reported to ISMA within 30 
minutes- To facilitate this requirement, an ISMA system 
called "TRAX" is used. 

TRAX is ISMA's real-time electronic trade matching, 
confirmation and regulatory reporting system. All executions 
on the system 100 must be reported to TRAX by the system 100 
and the two client contra-sides . TRAX compares all sides of 
an execution and reports results back to all submitting sides. 
Confirmation that all submitting sides are in agreement 
regarding execution details does not guarantee that a given 
25 trade will settle. The purpose of TRAX reporting is to alert 
submitters to errors that could interfere with settlement in a 
timely manner. 

A Cenrral Securities Depository (CSD) is an institution that 
provides central vaulting of certificates (if certificates 
30 exist) and maintains security transfer and ownership records. 
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serve clients domiciled in a given country. Specific services 
can vary from one country to another, but they generally act 
as Transfer Agent and Paying Agent. If a customer of a CSD 
needs to settle a cross-border trade, the local CSD can 
interact with an ICSD or a Settlement Agent to facilitate the 
settlement process. 

An International Central Securities Depository (ICSD) is 
similar to a CSD, except that its services are used to settle 
"cross-border" trades. An ICSD acts as Transfer Agent and 
Paying Agent. CSDs can interact with ICSDs in order to 
facilitate settlement of cross-border trades. From a system 
perspective, the system deals with ICSD which reports to an 
agent. The agent typically uses a local settlement processes. 

Two examples of ICSDs are Euroclear and Cedel. Euroclear is 
an international depository, located in Brussels, formed to 
provide exchange and clearance services for internationally 
traded securities. Euroclear has an "electronic bridge," or a 
direct link, to the Cedel depository to facilitate settlements 
between the two ICSDs. The system 100 can maintain accounts 
with an ICSD for settlement purposes.' i. 

Cedel (Centrale de Livraison de Valeurs Mobilieres) is the 
second major depository, along with Euroclear, for 
international trading. Located in Luxembourg, Cedel works 
with Euroclear to facilitate transaction flows. An example of 
the cooperation between these two depositories, which results 
in efficiency for participants, is that Cedel performs pre- 
matching of trades with Euroclear daily to ensure timely 
delivery and receipt. Benefits of Cedel ' s working 
relationship with Euroclear include fewer physical settlements 
which result in lower fees charged to participants, and same 
day cache proceeds. 
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settlement .^ents .etv, as . local intermediary between the 
sy.ten, 100 (Via its Euroclear account, and local CSOs . 

x: pfficiencv. example, in 

Settlement Agents facilitate ef-iciency 

order to do business with a given CSD, it is necessary to meet 
specific business and regulatory requirements. Because o£ the 
diversity of requirements among CSDs and the differing 
regulatory environments of each country, it is efficient to 
use a settlement Agent that meets all the necessary 
requirements to do business in a local market. Preferably, 
. the system uses two such agents: Citibank and Paribus. 

The following discussion relates to systems and components 

that facilitate settlement in a European marketplace. .A 

-caoital Markets Package" (C«P) 240 is software licensed 

thr'ough Wilco International Limited. CMP 240 is the system's 

w V .nH records" and the main "engine" driving a 
European "books and recoras au^i 

moHp^l -tbat recuires minimal manual 
European settlement model T:n« . 

intervention. The CMP 240 interfaces with the core components 
122 via the Back Office adapter 1221c, and is preferably 
resident in a data center (e.g., 120) corresponding to the 
European market, for example. From a functional viewpoint, 
the Back Office Adapter 122k preforms in a similar manner as 
does its U.S. market counterpart. 

When the CMP 240 receives a trade, it enhances the trade data 
with settlement information from the static data stored in xts 
own database. This information is important because there xs 
no single entity responsible for settlement. Because the 
svstem 100 acts as the contra-side for each trade (thereby 
ensuring the anonymity of each trade s.de) , the system 100 
must settle with each client according to each client's 
^reference. For example, one client may utilize a local CSD, 
Lhile another may have an account w.th Cedel. CMP 240 inserts 
settlement information of th.s kxnd so the correct settlement 
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instructions are given to the various software components that 
facilitate settlement of the fixed instrument transactions. 

The CMP 240 generates a TRAX instruction to meet the THAX 
reporting requirement. CMP 240 also receives messages from 
the TRA.X systam that advise CMP 240 of the trade's status 
(e.g., whether its details matched those reported by the 
contra-side). The CMP 240 can also generates a fax 
confirmation to the counterparts, if required by a client. 
The CMP 240 generates a SWIFT settlement message to instruct 
the settlement entities regarding the trade and facilitate the 
settlement transaction. CMP also receives SWIFT messages, as 
discussed below, to update the settlement status of 
transactions. The CMP 240 also issues instructions to 
SmartStream, the auto-reconciliation software, discussed 
below, produces files for system 100 finance and compliance 
departments for tracking purposes, and archives the 
transaction to an optical disk (not shown). 



As will be appreciated by those familiar with fixed income 
instruments, SmartStream is a reconciliation system for Depots 
and Nostro accounts, trade accounts ana for transactions. 

SmartStream provides information regarding the settlement 
status of trades, as well as reconciliations among the various 
systems and clearing entities. 

SWIFT is an acronym for Society For Worldwide Interbank 
Financial Telecommunications. SWIFT is a system of electronic 
communication that facilitates the exchange of trading and 
settlement messages, as well as payment instructions and cache 
transfers between financial institutions around the world. 
SWIFT messages can be sent both internationally and 
domestically . 
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SWIFT provides common rules, standards and communication 
methods for users of financial services. SWIFT protects 
against unauthorized access, loss or incorrect delivery of 
messages, transmission errors, loss of confidentiality and 
fraudulent changes to messages. 

The following discussion describes how a trade is processed by 
the system's components and external settlement agencies to 
facilitate settlement in a European market. 

When a trade occurs, the system 100 protects each side's 
identity by reporting itself as the contraside. For example, 
consider a situation where Firm A and Firm B trade on the 
system 100, as illustrated in Figure 19. The system 100 
protects the identity of all clients, so the system 100 is the 
contra-side from Firm A and Firm B's perspective. This 
execution information is provided to CMP 240 via the Back 
Office Adapter 12 2k for post-trade processing. 

Reporting to TRAX must occur within thirty minutes of 
execution. When CMP 240 receives an execution from the Back 
office Adapter 12 2k, it immediately issues a message to the 
TRAX server 251, which forwards the information to the TRAX 
system 250. SmartStream 260 also receives notification that 
the TRAX message was sent, so it can monitor the response from 
TRAX. Each contra-side also reports the trade to TRAX within 
the thirty minutes, as shown in Figure 20. 

CMP 240 enriches the "execution data with settlement 
instructions, and issues a SWIFT message to the entities 
involved in the settlement. SmartStream 26 0 also receives the 
SWIFT instructions and updates the trade status accordingly. 
Typically, the CMP 240 enriches the execution data with 
settlement instructions and issues a SWIFT message immediately 
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CMP 240 does not wait for a response back from TRAX before 
proceeding with post trade processing. 

Settlement inf orETiation for each system 100 client is 
maintained directly in the CMP 240, using a menu-driven 
administrator interface 241. Settlement instructions are 
necessary because there is no single centralized clearing and 
settlement entity in Europe. The entity utilized to 
facilitate settlement (e.g., a ICSD or CDS) varies from 
location to location. 

The TRAX system 250 matches the trade details and reports the 
results back to all sides, as shown in Figure 21. A TRAX- 
reported match is not a confirmation that the trade will 
settle. TRAX reporting only confirms whether the reported 
trade details match among the parties involved. CMP 240 and 
SmartStream 2 60 receives the TRAX response and updates the 
trade status accordingly. Notification of a failed trade can 
be issued through ISCD, via SWIFT. 

Once settlement has occurred, the clearing entities 138 
involved notify the system 100 and the contra-side fir^s via 
SWIFT. SmartStream 260 listens for the incoming SWIFT 
messages and updates the trade status accordingly (see Figure 
22). At the end of the trading day, CMP 240 batch processes 
the days activity and creates files to update the Finance and 
Compliance departments' systems (see Figure 22). 

While the present invention has been described with respect to 
what is presently considered to be the preferred embodiments, 
it :ls to be understood that the invention is not limited to 
the disclosed embodiments. To the contrary, the invention is 
intended to cover various modifications and equivalent 
arrangements included within the spirit and scope of the 
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accorded the broadest interpretation so as to encompass all 
such modifications and equivalent structures and functions. 
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V/hat Ls Claimed : 



i?) A trading system for trading fixed income 
instruments, the system comprising: 

at least two server computers, each comprising: 
a first interface to communicate with a server 

computer; 

a second interface through which orders are received 

by said system; 

at least one processor for executing, computer code; 

a first database pertaining to trading activity 
through said system in a first trading market; 

a second database pertaining to trading activity 
through said system in a second trading market; 

at least one cache storing information regarding 
market activity in the respective first or second market; 

a memory having computer executable code stored 
thereon, the code for (i) updating said first and second 
databases and said at least one cache; (ii) synchronizing the 
updates; and (ii) processing orders from each respective 
trading market . 



2. The trading system according to Claim 1, wherein 
each" of said two server computers is located in a 
geographically separate location. 

3. The trading system according to Claim 2, further 
comprising at least one trader site comprising at least one 
application server and a workstation connected to said at 
least one application server. 

4. The trading system according to Claim 3, wherein 
said at least one application server contains a cache having 
at least a cooy of the information in said first database 
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5. The trading system according to Claim 4, wherein 
the code i) updates the cache in the at least one application 
server, and ii) synchronizes the updates with the updates to 
said first and second databases. 

6. The trading system according to Claim 1, wherein 
the code maintains at least one instrument book defined by a 
set of bids and offers and by a settlement date- 

7. The trading system according to Claim 6, wherein 
the code changes a status of the at least one instrument book. 

8. The trading system according to Claim 1, wherein 
a status comprises open, closed, inactive and retired, 

9. The trading system according to Claim 6, wherein 
the code ranks a bid having a highest price first among other 
bids in the at least one book. 

10. The trading system according to Claim 5, 
wherein the code ranks an offer having the lowest price first 
among other offers in the at least one book. 

I 

11. The trading system according to Claim 6, 
wherein the code ranks passive orders having a same price in 
the at least one instrument book on a first come, first serve 
basis with respect to each other. 



12. The trading 
wherein the code processes 
first serve basis. 



system according to Claim 6, 
aggressive orders on a first 



come. 
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13. The trading system according to Claim 6, 
wherein the code removes from the at least one book a passive 
bid or passive offer once the passive bid or passive offer has 
been executed. 



14. The trading system according to Claim 6, 
wherein the code validates orders. 

15. The trading system according to Claim 6, 
wherein a user terminal is interfaced with the system. 

16. The trading system according to Claim 15, 
wherein the at least one book is configured for display 
through the user terminal. 

17. The trading system according to Claim 14, 
wherein the code filters data transmitted to the user 
terminal . 

18. The trading system according to Claim 1, 
wherein the code causes said system to transfer information 

related to executed transactions throuigh the trading system to 

I, 

at least one clearing entity. 

19. A trading apparatus comprising: 

at least one network server comprising: 

at least one processor which executes computer ■ 
executable code; 

an interface through which orders are received by 
said trading apparatus; 

a memory for storing computer executable code, the 
code including steps for (i) maintaining at least one 
instrument book defined by a set of bids and offers and by a 
settlement date; (ii) processing passive orders; (iii) 
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the aggressive orders; and (vj orocessins a sweep order for 
the at least one instrument book. 

20. The trading apparatus according to Claim 19, 
wherein the sweep order is an order to aggress multiple 
passive orders at a selected, price option and amount. 

21. The trading apparatus according to Claim 20, 
wherein the code aggresses passive orders to fill the sweep 
order by sequentially i) executing shown amounts of passive 

•orders at the selected price; ii) executing reserve amounts at 
the selected price when needed to fill the sweep order; and 
iii) executing passive orders at a next price when needed to 
fill the sweep order. 

22. The trading apparatus according to Claim 21, 
wherein the code expires a first passive order listed in the 
at least one instrument book when i) the code determines that 
the first passive order was submitted by a trader who also 
submitted the sweep order, and ii) the code executes a second 
passive order that is listed below the first passive order. 

23. The trading apparatus according to Claim 19, 
wherein a first passive order comprises price and amount 
information , 

24- The trading apparatus according to Claim 23, 
wherein the first passive order further comprises shown amount 
information, and the code determines a reserve amount from the 
shown amount. 

, -v.v.> • '25.' The trading apparatus according to Claim 24, 
v/herein at least one user terminal is interfaced v/ith said 
trading apparatus and the code conditionally conceals the 
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26. The trading apparatus according to Clain 25, 
wherein the codes conveys the reserve amount to the at least 
one user terminal when a condition comprises a user who 
entered the first passive • order . 

27. The trading apparatus according to Claim 24^ 
wherein the code executes a shown amount prior to executing a 
reserve amount* 

28. The trading apparatus according to Claim 27, 
wherein the code executes shown amounts for orders at a same 
price in an instrument book before- executing reserve amounts 
for the orders at the same price. 

29. A trading apparatus comprising: 

at least one network server comprising: 

at least one processor which executes computer 

executable code; 

an interface through which orders are received by- 
said trading apparatus; 

a memory for storing computer executable code, the 
code including steps for (i) maintaining at least one ^ 
instrument book defined by a set of bids and offers and by a 
settlement date; (ii) processing passive orders; (iii) 
processing aggressive orders; (iv) executing trades based on 
the aggressive orders, 

wherein said steos process aggressive orders each 
comprising instrument identification, price option 
information, amount information and minimum amount for 
execution information . 

30. The trading apparatus according to Claim 29, 
wherein the code executes a trade only when a total amount of 
shown and reserve amounts for orders at the order price option 
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in the at least one instrument book equals at least the 
minimum amount for execution. 

31. The trading apparatus according to Claim 30 , 
wherein the code generates an execution notification regarding 
the order cnly when a trade is executed. 

32. A trading apparatus comprising: 

at least one network server comprising: 

at least one processor which executes computer 

•executable code; 

an interface through which orders are received by 

said trading apparatus; 

a memory for storing computer executable code, the 
code including steps for.(i) maintaining at least one 
instrument book defined by a set of bids and offers and by a 
settlement date; (ii) processing passive orders; (iii) 
processing aggressive orders; (iv) executing trades based on 
the aggressive orders; and (v) wherein aaid ktkfi^ ^ocess 
aggressive orders each comprising instrument identification, 
price option criteria, amount information, and a post residual 
authorization, t 

33. The trading apparatus according to Claim 32, 
wherein the code converts an unfilled balance of the first 
aggressive order into a passive order having an aggressed-on 
price. 

34. The trading apparatus according to Claim 33, 
wherein the code posts the unfilled amounc in the at least one 
book as a shown amount. 
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35. The trading dpparatus according to ClaiKi 33, 
wherein the code posts the unfilled amount in the at least one 
instrument book as a shown amount and the remainder as a 
reserve amount. 

36. A trading apparatus comprising: 

at least one network server comprising: 

at least one processor which executes computer 

executable code; 

an interface through which orders are received by 

said- trading apparatus; 

a memory for storing computer executable code, the 
code including steps for (i) maintaining at least one 
instrument book defined by a set of bids and offers and by a 
settlement date; (ii) processing passive orders; (iii) 
processing aggressive orders; (iv) executing trades based on 
the aggressive orders; and (v) suspending all orders submitted 
by a user through a user terminal when communication with the 
user terminal is interrupted. 

37. A trading apparatus comprising: 

at least one network server comprising: 

t. 

at least one processor which executes computer 
executable code; 

an interface through which orders are received by 
said trading apparatus; 

a memory for storing computer executable code,. the 
code including steps for (i) maintaining at least one 
instrument book defined by a set of bids and offers and by a 
settlement date; (ii) processing passive orders; (iii) 
processing aggressive orders; (iv) executing trades based on 
the aggressive orders; and (v) canceling all orders received 
from a user through a user terminal in response to a user 
generated bulk cancel request. 
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38. A trading apparatus comprising: 

at least one network, server comprising: 

at least one processor which executes computer 

executable code; 

an interface through which orders are received by 

said trading apparatus; 

a memory for storing computer executable code, the 
code including steps for (i) maintaining at least one 
instrument book defined by a set of bids and offers and by a 
.settlement date; (ii) processing passive orders; (iii) 
•processing aggressive orders; (iv) executing trades based on 
the aggressive orders; and (v) suspending all orders received 
from a user through a user terminal in response to a user 
generated bulk suspend request. 

39. A trading apparatus comprising: 

at least one network server comprising: 

at least one processor which executes computer 

executable code; 

an interface through which orders are received by 
said trading apparatus; 

a memory for storing computer executable , code , the 
code including steps for (i) maintaining at least one 
instrument book defined by a set of bids and offers and by a 
settlement date; (ii) processing passive orders; (iii) 
processing aggressive orders; (iv) executing trades based on 
the aggressive orders; and (v) converting passive orders into 
an aggressive orders and executing the converted aggressive 
orders at a top of book price, when the passive orders invert 
a market. 

40. The trading apparatus according to Claim 39, 
wherein a first passive order inverts the market when the 
first passive order comprises a bid having a higher price than 
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or when the first passive order comprises an offer having a 
lower price than the highest priced bid in the at least one 
instrument book. 

41. A trading apparatus comprising: 

at least one network server comprising: 

at least one processor which executes computer 

executable code; 

an interface through which orders are received by 

said trading apparatus; 

a memory for storing computer executable code, the 
code including steps for (i) maintaining at least one 
instrument book defined by a set of bids and offers and by a 
settlement date; (ii) processing passive orders; (iii) 
processing aggressive orders; (iv) executing trades based on 
the aggressive orders; and (v) ex£irin3 all orders at the end 
of a trading day- 

42. A trading apparatus comprising: 

at least one network server comprising: 

at least one processor which executes computer 

executable code; ^ 

an interface through which orders are received by 

said trading apparatus; 

a memory for storing computer executable code, the 
code including steps for (i) maintaining at least one 
instrument book defined by a set of bids and offers and. by a 
settlement date; (ii) processing passive orders; (iii) 
processing aggressive orders; (iv) executing trades based on 
the aggressive orders; and (v) expiring orders based on user 
selected criteria. 

43. The trading apparatus according to Claim 42, 
wherein the code expires a first order, comprising good until 
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better price than the first order is entered into the dt ledst 
one instrument book.. 

44. The trading dpparatus according to ClaLu 42, 
wherein the user • selected criteria comprises good until 
topped, good until time, good until canceled, and good until 
end of day. 

45, Media containing computer executable code to 
generate a graphic user interface invocable by programable 
software for use in a fixed income trading system, the system 
providing a computerized venue for trading instruments, the 
system receiving orders including bids and offers for 
individual instruments submitted to the system, the system ^ 
maintaining at least one book defined by a set of orders and 
by a settlement date, the graphic user interface for 
employment on a trader work station connected to said system, 
the computer executable code comprising: 

steps to generate a first window comprising a first 
display region displaying a top of book view, a second display 
region displaying a key issues view, a third region displaying 
a depth of book view, and a forth region inclvding at least 
one user activatible button to invoke an order entry dialog 
box through which a user inputs order requests into the 
system. 

46. The media according to Claim 45, wherein the 
computer executable code further comprises steps for 
generating a region including a user activatible button for 
displaying a floating book window. 

47. • The media according to Claim 46, wherein the 
floating book comprises a depth of book view and a region 
inciudina user activatible buttons to invoke at least one 
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48. The media according to Claim 45, wherein said 
first window further comprises a region having a pull-down 
menu including a user activated preference dialog box, the 
dialog box accepting user entered default settings for orders. 

49. The media according to Claim 48, said computer 
executable code further includes steps for generating -a 
shortcut order entry menu for invoking an order entry dialog 
box comprising the default settings for the individual 
instrument, when an individual instrtiment displayed on said 
first window is activated. 

50. The media according to Claim 45, wherein said 
first window further comprises a fifth region for displaying a 
moving real-time ticker comprising instrument information. 

51. Media containing computer executable code to 
generate a graphic -user interface invocable by a software 
program, said graphic user interface for use by brokers in a 
trading system, the trading system providing a computerized 
venue for trading instruments, the code comprising: 

steps to generate a first window displaying a ^ 
scrolling list of real-time market activity that occurs 
through the system, the first window including a first region 
having a puli-do\^ menu for a user activatible filter for 
selecting a subset of activity to view for real-time display; 
and 

steps to generate a second window displaying a 
client-specific blotter comprising order history information, 
order status information, and user activated transactions, 

wherein a broker accessing the second windov/ can 
interface with the system on behalf of the specified client. 
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52. A graphic user interface accordiag to Claim 51, 
wherein an activity subset comprises market type, instrument 
or client. 

53. A network trading system comprising: 

at least one server including at least one processor 
for executing computer code; 

an interface through which a user gains access to 

said system; 

at least one memory having computer executable code 
stored thereon, the code for: (i) tracking activity through 
the system with respect to individual trading, instruments; 
(ii) organizing for real-time display the tracked activity of 
individual trading instruments; and (iii) displaying to the 
user a subset of the tracked activity. 



54. A fixed income securities trading system, 
comprising: 

a data hub including a processor and a memory for 
storing and updating a plurality of trade books, each book 
5- corresponding to at least one fixed income securities 

instrument, each book having data corresponding to^(i) system 
clients, (ii) offers of said clients for sales of said at 
least one fixed income securities instrument, (iii) bids of 
said clients for purchases of said at least one fixed income 
10 securities instrument, and (iv) status of said offers and said 
bids; and 

a plurality of trader workstations, each coupled to 
said data hub and displaying at least one of said plurality of 
trade books, each workstation transmitting to said data hub 
15 (i) offers of the said clients for sales of said at least one 
fixed income securities instrument, (ii) bids of said clients 
for purchases of said at least one fixed income securities 
instrument, and (iii) in instruction to either accept an offer 
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for sale or a bid for purchase of said at least one fixed 
income securities instruments- 
said data hub, in response to receipt of said 
instruction, executing the trade and updating said book 
status, said data hub outputting a clearing entity resolution 
signal to a clearing entity. 

55. A method of operating a computerized fixed 
income securities trading system, comprising steps of : 

storing in a computerized data hub a plurality of 
trade books, each book corresponding to at least one fixed 
income securities instrument, each book having data 
corresponding to (i) system clients, (ii) offers of said 
clients for sales of said at least one fixed income securities 
instrument, (iii) bids of said clients for purchases of said 
at least one fixed income securities instrument, and (iv) 
status of said offers and said bids; 

displaying said each book at a plurality of remote 
computerized trader workstations coupled to said data hub; 

updating said each book in response to a client 
offer for sale of said at least one fixed income securities 
instrument input from a trader workstation; ^ 

updating said each book in response to a client bid 
for purchase of said at least one fixed income securities 
instrument input from a trader workstation; 

in response to in instruction from a trader 
workstation to either accept an offer for sale or a bid for 
purchase of said at least one fixed income securities 
instrument, executing the trade and updating said book status; 
and 

after the execution of the trade, outputting a 
clearing entity resolution signal to a clearing entity. 
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